You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
-[Progressive Web App Metadata](#progressive-web-app-metadata)
33
37
-[Deployment](#deployment)
34
38
-[Static Server](#static-server)
35
39
-[GitHub Pages](#github-pages)
@@ -63,23 +67,28 @@ const db = new PouchDB('mydb');
63
67
```
64
68
65
69
## Folder structure
70
+
66
71
```
67
72
my-app/
68
-
.gitignore
69
-
README.md
70
-
elm-package.json
71
-
public/
72
-
favicon.ico
73
-
index.html
74
-
src/
75
-
Main.elm
76
-
index.js
77
-
main.css
78
-
tests/
79
-
elm-package.json
80
-
Main.elm
81
-
Tests.elm
73
+
├── .gitignore
74
+
├── README.md
75
+
├── elm-package.json
76
+
├── elm-stuff
77
+
├── public
78
+
│ ├── favicon.ico
79
+
│ ├── index.html
80
+
│ ├── logo.svg
81
+
│ └── manifest.json
82
+
├── src
83
+
│ ├── Main.elm
84
+
│ ├── index.js
85
+
│ ├── main.css
86
+
│ └── registerServiceWorker.js
87
+
└── tests
88
+
├── Tests.elm
89
+
└── elm-package.json
82
90
```
91
+
83
92
For the project to build, these files must exist with exact filenames:
84
93
85
94
-`public/index.html` is the page template;
@@ -317,6 +326,109 @@ To use packages in tests, you also need to install them in `tests` directory.
317
326
elm-app test --add-dependencies elm-package.json
318
327
```
319
328
329
+
## Making a Progressive Web App
330
+
331
+
By default, the production build is a fully functional, offline-first
332
+
[Progressive Web App](https://developers.google.com/web/progressive-web-apps/).
333
+
334
+
Progressive Web Apps are faster and more reliable than traditional web pages, and provide an engaging mobile experience:
335
+
336
+
* All static site assets are cached so that your page loads fast on subsequent visits, regardless of network connectivity (such as 2G or 3G). Updates are downloaded in the background.
337
+
* Your app will work regardless of network state, even if offline. This means your users will be able to use your app at 10,000 feet and on the Subway.
338
+
* On mobile devices, your app can be added directly to the user's home screen, app icon and all. You can also re-engage users using web **push notifications**. This eliminates the need for the app store.
339
+
340
+
The [`sw-precache-webpack-plugin`](https://github.com/goldhand/sw-precache-webpack-plugin)
341
+
is integrated into production configuration,
342
+
and it will take care of generating a service worker file that will automatically
343
+
precache all of your local assets and keep them up to date as you deploy updates.
344
+
The service worker will use a [cache-first strategy](https://developers.google.com/web/fundamentals/instant-and-offline/offline-cookbook/#cache-falling-back-to-network)
345
+
for handling all requests for local assets, including the initial HTML, ensuring
346
+
that your web app is reliably fast, even on a slow or unreliable network.
347
+
348
+
### Opting Out of Caching
349
+
350
+
If you would prefer not to enable service workers prior to your initial
351
+
production deployment, then remove the call to `serviceWorkerRegistration.register()`
352
+
from [`src/index.js`](src/index.js).
353
+
354
+
If you had previously enabled service workers in your production deployment and
355
+
have decided that you would like to disable them for all your existing users,
356
+
you can swap out the call to `serviceWorkerRegistration.register()` in
357
+
[`src/index.js`](src/index.js) with a call to `serviceWorkerRegistration.unregister()`.
358
+
After the user visits a page that has `serviceWorkerRegistration.unregister()`,
359
+
the service worker will be uninstalled. Note that depending on how `/service-worker.js` is served,
360
+
it may take up to 24 hours for the cache to be invalidated.
361
+
362
+
### Offline-First Considerations
363
+
364
+
1. Service workers [require HTTPS](https://developers.google.com/web/fundamentals/getting-started/primers/service-workers#you_need_https),
365
+
although to facilitate local testing, that policy
366
+
[does not apply to `localhost`](http://stackoverflow.com/questions/34160509/options-for-testing-service-workers-via-http/34161385#34161385).
367
+
If your production web server does not support HTTPS, then the service worker
368
+
registration will fail, but the rest of your web app will remain functional.
369
+
370
+
1. Service workers are [not currently supported](https://jakearchibald.github.io/isserviceworkerready/)
371
+
in all web browsers. Service worker registration [won't be attempted](src/registerServiceWorker.js)
372
+
on browsers that lack support.
373
+
374
+
1. The service worker is only enabled in the [production environment](#deployment),
375
+
e.g. the output of `npm run build`. It's recommended that you do not enable an
376
+
offline-first service worker in a development environment, as it can lead to
377
+
frustration when previously cached assets are used and do not include the latest
378
+
changes you've made locally.
379
+
380
+
1. If you *need* to test your offline-first service worker locally, build
381
+
the application (using `npm run build`) and run a simple http server from your
382
+
build directory. After running the build script, `create-react-app` will give
383
+
instructions for one way to test your production build locally and the [deployment instructions](#deployment) have
384
+
instructions for using other methods. *Be sure to always use an
385
+
incognito window to avoid complications with your browser cache.*
386
+
387
+
1. If possible, configure your production environment to serve the generated
If that's not possible—[GitHub Pages](#github-pages), for instance, does not
390
+
allow you to change the default 10 minute HTTP cache lifetime—then be aware
391
+
that if you visit your production site, and then revisit again before
392
+
`service-worker.js` has expired from your HTTP cache, you'll continue to get
393
+
the previously cached assets from the service worker. If you have an immediate
394
+
need to view your updated production deployment, performing a shift-refresh
395
+
will temporarily disable the service worker and retrieve all assets from the
396
+
network.
397
+
398
+
1. Users aren't always familiar with offline-first web apps. It can be useful to
399
+
[let the user know](https://developers.google.com/web/fundamentals/instant-and-offline/offline-ux#inform_the_user_when_the_app_is_ready_for_offline_consumption)
400
+
when the service worker has finished populating your caches (showing a "This web
401
+
app works offline!" message) and also let them know when the service worker has
402
+
fetched the latest updates that will be available the next time they load the
403
+
page (showing a "New content is available; please refresh." message). Showing
404
+
this messages is currently left as an exercise to the developer, but as a
405
+
starting point, you can make use of the logic included in [`src/registerServiceWorker.js`](src/registerServiceWorker.js), which
406
+
demonstrates which service worker lifecycle events to listen for to detect each
407
+
scenario, and which as a default, just logs appropriate messages to the
408
+
JavaScript console.
409
+
410
+
1. By default, the generated service worker file will not intercept or cache any
411
+
cross-origin traffic, like HTTP [API requests](#integrating-with-an-api-backend),
412
+
images, or embeds loaded from a different domain. If you would like to use a
413
+
runtime caching strategy for those requests, you can [`eject`](#npm-run-eject)
0 commit comments