3 ms·

The code seems generate to generate a very simple service worker that enables offline more for the web app: it puts the static assets in a cache that serves the

by isoos 9y ago

The code seems generate to generate a very simple service worker that enables offline more for the web app: it puts the static assets in a cache that serves them if the network is down. While it is a great start, and nothing wrong with that, I encourage people to check the more advanced features of routing and caching, where you have much better control of what is happening in the service worker. I have found the best JS library for that is sw-toolbox: https://github.com/GoogleChrome/sw-toolbox https://github.com/GoogleChrome/sw-toolbox Shameless plug: I have also developed a Dart library for progressive web apps: https://github.com/isoos/pwa https://github.com/isoos/pwa One significant advantage of the library over the original solution is that you can have offline mode without sweating as much as 100-ish characters: https://medium.com/dartlang/making-a-dart-web-app-offline-capable-3-lines-of-code-e980010a7815 https://medium.com/dartlang/making-a-dart-web-app-offline-ca... (Scroll ~to the middle, super-simple to setup). Another advantage is that cache invalidation is really hard. Neither the linked quickstart, nor the sw-toolbox addresses this, but there should be a way to control your cache updates, invalidations, and making sure you don't leave it in a broken state. Also, these should make sure that you don't pollute the user's browser too much. My pwa package does cover a lot of these edge-cases, and I'm happy to answer questions wrt/ pwa caching if there are any. (Next up: messaging solution between service workers, web workers, isolates...)

aussieguy1234 9y ago
From my testing, the service worker served cached assets without requesting to the network, unless you cleared the cache or had automatic reloads enabled in chrome devtools. You can control invalidations a from chrome devtools. Assets get served from the cache unless it's invalidated. A chokidar powered script also watches for cached asset changes and regenerates the service worker (using sw-precache) with a new cache key.
- isoos 9y ago
  Couple of things are mixed up here. 1) You may instruct a developer that they should clear their caches in Chrome DevTools. Good luck telling that to my father, who will have no clue what you are talking about. Cache invalidation is not only a technical issue, it affects the user experience, and should be an active part of your design. If your low-level tool does not support it, you need to be aware of that, and should write the code that does support it. 2) Automatically regenerating the serviceworker is the minimum you shall do, but there are other error scenarios that may happen: - You accidentally cache hundreds of 10MBs assets, taking up a huge space of your users. You roll out the new version, these assets are no longer cached, but unless you evict them actively, they will still take up space on the user's computers. - A cache request fails (for whatever reason), and one of the 29 assets goes missing in the cache. The app may be able to run offline, except that it will not show an icon, or will not run an asynchronously loaded script. - A cache update may fail during re-populating the cache (e.g. computer powered off), and the next time the offline app is loaded, the cache stores a mixture of old and new assets. 3) There are several layers of caches between the pixels and the server assets (to name a few: CDNs, web proxies, browser's disk cache, service worker's cache). Being aware that any of them may produce a different version of the same resource will usually help you to design a better tolerance for the edge cases.

by isoos 9y ago

aussieguy1234 9y ago

From my testing, the service worker served cached assets without requesting to the network, unless you cleared the cache or had automatic reloads enabled in chrome devtools. You can control invalidations a from chrome devtools. Assets get served from the cache unless it's invalidated. A chokidar powered script also watches for cached asset changes and regenerates the service worker (using sw-precache) with a new cache key.

isoos 9y ago
Couple of things are mixed up here. 1) You may instruct a developer that they should clear their caches in Chrome DevTools. Good luck telling that to my father, who will have no clue what you are talking about. Cache invalidation is not only a technical issue, it affects the user experience, and should be an active part of your design. If your low-level tool does not support it, you need to be aware of that, and should write the code that does support it. 2) Automatically regenerating the serviceworker is the minimum you shall do, but there are other error scenarios that may happen: - You accidentally cache hundreds of 10MBs assets, taking up a huge space of your users. You roll out the new version, these assets are no longer cached, but unless you evict them actively, they will still take up space on the user's computers. - A cache request fails (for whatever reason), and one of the 29 assets goes missing in the cache. The app may be able to run offline, except that it will not show an icon, or will not run an asynchronously loaded script. - A cache update may fail during re-populating the cache (e.g. computer powered off), and the next time the offline app is loaded, the cache stores a mixture of old and new assets. 3) There are several layers of caches between the pixels and the server assets (to name a few: CDNs, web proxies, browser's disk cache, service worker's cache). Being aware that any of them may produce a different version of the same resource will usually help you to design a better tolerance for the edge cases.