Get the main page URL from a Service Worker

Question

I am trying to migrate from AppCache to Service Worker for a large framework (Construct 2 - see www.scirra.com). It is easy to find examples of how to cache a list of resources with Service Worker and then respond with cached entries in the fetch event. However there are two features of AppCache that I'm finding harder to replicate with Service Worker:

1. Automatic caching of the main page.
2. Check for an update by requesting a separate file (offline.json) when the main page loads.

Both of these need to identify the index page (#2 would check for an update at the same time the index page is requested). However I'm finding myself led in to what seem like inelegant solutions. Note that many servers return "foo/index.html" if "foo/" is requested, but others don't, and still others use dynamic paths, so I can't list any hard-coded main page URLs. I have to go by the current page's URL.

For #1, I skipWaiting() in the "install" event, claim() clients in "activate", clients.matchAll() to iterate every client and then add client.url to the cache. This seems a bit long-winded, is there not a way to get the main page URL in the "install" event?

For #2, I have to call clients.matchAll() in every fetch event and test if the current request URL matches any of the client URLs. If it does it's the main page and I check for an update, otherwise handle normally. This seems really inelegant, since every one of the hundreds of fetch requests happening while the page loads has to keep getting a list of all the clients and matching their URLs.

Is there not a better way to get the URL of the main page from a service worker?

Answer 1

I'd recommend incorporating sw-precache into your build process. It generates a service worker script for you that will take care of precaching the resources you care about, as well as maintaining the cache (updating/adding/deleting) entries when changes are detected during your build.

There's some support in sw-precache for precaching URLs that depend on multiple underlying template files, but you can also use sw-precache in conjunction with additional runtime service worker logic. sw-toolbox is a library that compliments sw-precache nicely and implements various runtime caching options.

Even if you don't use sw-precache directly, here are a few patterns taken from its code that you could follow in your own service worker:

• Add an index file, like index.html , to the request URL if it ends in / . (When using the Cache Storage API from within a service worker, it's always a good idea to normalize the URLs you're using as keys.)

• Rely on the service worker lifecycle to trigger cache management instead of fetching an out-of-band "manifest". When your browser notices a change to your service worker script, it will fire an install event to give you a chance to cache new entries, and an activate event to give you a chance to do cache cleanup. This implies that whenever there are changes to your cached entries, your underlying service worker script changes. A straightforward, but error-prone, way of doing this is to include a version string inline in your service worker script. A less error-prone approach is to automatically modify your service worker script whenever there's a change to the underlying resources you're caching, and that's what sw-precache does for you. From within your controlled pages, you can listen for specific service worker lifecycle events and display a "New content is available; please refresh!" message or the like.