There are conceptually two kinds of updates, and it isn’t clear from your question which we’re talking about, so I’ll cover both.
Updating content
Eg:
- The text of a blog post
- The schedule for an event
- A social media timeline
These will likely be stored in the cache API or IndexedDB. These stores live independently of the service worker – updating the service worker shouldn’t delete them, and updating them shouldn’t require an update to the service worker
Updating the service worker is the native equivalent of shipping a new binary, you shouldn’t need to do that to (for example) update an article.
When you update these caches is entirely up to you, and they aren’t updated without you updating them. I cover a number of patterns in the offline cookbook, but this is my favourite one:
- Serve page shell, css & js from a cache using the service worker.
- Populate page with content from the cache.
- Attempt to fetch content from the network.
- If the content is fresher than what you have in the cache, update the cache and the page.
In terms of “update the page”, you need to do that in a way that isn’t disruptive to the user. For chronological lists this is pretty easy, as you just add the new stuff to the bottom/top. If it’s updating an article it’s a bit trickier, as you don’t want to switch text from underneath the user’s eyes. In that case it’s often easier to show some kind of notification like “Update available – show update” which, when clicked, refreshes the content.
Trained to thrill (perhaps the first ever service worker example) demonstrates how to update a timeline of data.
Updating the “app”
This is the case where you do want to update the service worker. This pattern is used when you’re:
- Updating your page shell
- Updating JS and/or CSS
If you want the user to get this update in a non-atomic, but fairly safe way, there are patterns for this too.
- Detect updated service worker “waiting”
- Show notification to user “Update available – update now“
- When the user clicks this notification, postmessage to the service worker, asking it to call
skipWaiting. - Detect the new service worker becoming “active”
window.location.reload()
Implementing this pattern is part of my service worker Udacity course, and here’s the diff of the code before/after.
You can take this further too. For example, you could employ some kind of semver-esque system, so you know the version of the service worker the user currently has. If the update is minor you may decide calling skipWaiting() is totally safe.