mirror of https://github.com/embarklabs/embark.git
Framework for serverless Decentralized Applications using Ethereum, IPFS and other platforms
https://framework.embarklabs.io/
a609035182
TL;DR
=====
Unregister (disable) the service worker in production builds of Cockpit. The
CRA dev server doesn't enable the service worker, so no changes are needed in
that context, i.e. `yarn start` in the monorepo.
**NOTE**: to effect these changes a user will need to load production Cockpit at
`localhost:55555` and then close all Cockpit tabs (or restart the
browser). This should be done for each browser that has been used to access
production Cockpit. See the *Step-by-Step* section below for more information.
Rationale
=========
There are a couple of factors:
* It's a bit confusing that after stopping `embark run` the production build of
Cockpit is still accessible at `localhost:55555`. That's owing to CRA's
[offline-first behavior][PWA] per the service worker it creates, which
Cockpit [currently registers][current] (enables).
* It can be really confusing, if you don't know or forget about the service
worker's behavior, that after a production rebuild of Cockpit the old build
is still used in the browser, even after a page refresh. As [explained][ofb]
in CRA's docs: *"users will end up seeing older content until they
close (reloading is not enough) their existing, open tabs."* A similar effect
is seen when switching between DApps, e.g. teller and embark_demo.
The CRA docs point to [some code][code] that could be adapted to an alert in
the UI prompting the user to close all tabs and reopen the app. That approach
definitely makes sense for DApps built with CRA that have opted-in to the
service worker. In fact, the service worker behavior would be critical in DApps
that make use of connected-/react-router because cold loads of routes that
don't actually correspond to static files couldn't otherwise work, i.e. if the
DApp is being served from ipfs/swarm.
But for Cockpit itself, when served from localhost with an express backend that
we control, little seems to be gained from offline-first behavior vs. a more
familiar behavior, i.e. when `embark run` isn't running then Cockpit isn't
accessible.
Step-by-Step
============
Flushing a site's service worker from cache can be tricky. The following steps
outline an approach to making sure the Cockpit in use is the one with service
worker disabled.
1. The first screenshot below shows the JavaScript console from a fresh load of
Cockpit with the service worker enabled, i.e. from a build on `master` at time
of writing and `embark run` running for the `embark_demo`. Note the messages
re: *"workbox"* and *"precaching"*.
![][step-1]
2. The next screenshot shows what happens when `embark run` is stopped and the
browser is refreshed. Service worker makes the page available offline, though
there are errors related to embark's API not being accessible.
![][step-2]
3. (a) Cockpit gets rebuilt on this PR's `refactor/cockpit-service-worker`
branch and `EMBARK_UI_STATIC=t embark run` is started; see [previous
commit][prevcom] re: `EMBARK_UI_STATIC`. (b) The browser is refreshed. Note the
message at the bottom re: *"New content is available"*.
![][step-3]
4. The Chrome browser is closed completely (command-Q), reopened and
`localhost:55555` is loaded again. Note there are *still* messages re:
*"workbox"* and *"precaching"*.
![][step-4]
5. The page is refreshed again and now the messages are completely gone.
![][step-5]
6. `embark run` is stopped and the page is reloaded, but there's a connection
error because no process is listening on `localhost:55555` — proof that
the service worker is no longer in play!
![][step-6]
Steps 3(b) to 6 will need to be repeated for each browser (Firefox, Safari,
etc.) that visited `localhost:55555` when the service worker was enabled. And
they'll need to be repeated again if the browser is later used with a build of
Cockpit predating this PR.
[PWA]: https://facebook.github.io/create-react-app/docs/making-a-progressive-web-app
[current]:
|
||
|---|---|---|
| .github | ||
| dapps | ||
| packages | ||
| scripts | ||
| .editorconfig | ||
| .eslintrc.json | ||
| .gitignore | ||
| .npmrc | ||
| .travis.yml | ||
| .yarnrc | ||
| CHANGELOG.md | ||
| CODE_OF_CONDUCT.md | ||
| CONTRIBUTING.md | ||
| LICENSE | ||
| README.md | ||
| appveyor.yml | ||
| babel.config.js | ||
| header.png | ||
| lerna.json | ||
| package.json | ||
| tsconfig.json | ||
| tslint.json | ||
| yarn.lock | ||
README.md
What is Embark
Embark is a framework that allows you to easily develop and deploy Decentralized Applications (DApps).
A Decentralized Application is a serverless html5 application that uses one or more decentralized technologies.
Embark currently integrates with EVM blockchains (Ethereum), Decentralized Storages (IPFS), and Decentralized communication platforms (Whisper and Orbit). Swarm is supported for deployment.
With Embark you can:
Blockchain (Ethereum)
- Automatically deploy contracts and make them available in your JS code. Embark watches for changes, and if you update a contract, Embark will automatically redeploy the contracts (if needed) and the dapp.
- Contracts are available in JS with Promises.
- Do Test Driven Development with Contracts using Javascript.
- Keep track of deployed contracts; deploy only when truly needed.
- Manage different chains (e.g testnet, private net, livenet)
- Easily manage complex systems of interdependent contracts.
Decentralized Storage (IPFS, Swarm)
- Easily Store & Retrieve Data on the DApp through EmbarkJS. Including uploading and retrieving files.
- Deploy the full application to IPFS or Swarm.
- Import and deploy contracts hosted on Swarm.
Decentralized Communication (Whisper, Orbit)
- Easily send/receive messages through channels in P2P through Whisper or Orbit.
Web Technologies
- Integrate with any web technology including React, Foundation, etc..
- Use any build pipeline or tool you wish, including grunt, gulp and webpack.
$ npm -g install embark