Cache-first anti-pattern in SW example about simpl HOT 2 CLOSED

Thanks! I'll update.

On Fri, Sep 25, 2015 at 11:01 PM, Jeffrey Posnick [email protected]
wrote:

The code in
https://github.com/samdutton/simpl/blob/master/serviceworker/js/sw.js
precaches a list of resources in oninstall and then uses a cache-first
approach in the onfetch handler to serve the responses. The cached
entries are never updated outside of the oninstall handler.

In practice, this means that the resources which are cached the very first
time the page is opened on a given browser will be used indefinitely, until
the service worker's code is modified and oninstall is triggered again.
If you intend for this behavior, it should be highlighted prominently in
the comments/docs, as it's a non-trivial behavior that I'm sure most
developers won't be aware of. Most developers would assume that if they
modified, e.g., main.js, then that change would (eventually) trickle down
to their existing users.

Instead, I'd recommend following this example
https://github.com/GoogleChrome/samples/blob/gh-pages/service-worker/prefetch/service-worker.js#L27
and include an explicit cache versioning string in the service worker
script, along with instructions to developers that it needs to be bumped
each time a precached file changes.

Bonus points if you also cache-bust
https://github.com/GoogleChrome/samples/blob/gh-pages/service-worker/prefetch/service-worker.js#L56
the URLs used in the oninstall handler to ensure that when the cache
version string is updated, it actually results in a fresh resource being
retrieved from the network.

—
Reply to this email directly or view it on GitHub
#68.

from simpl.

Closing this — I added a large warning to the code a while back, and I'll update it at some stage.

from simpl.