Add a method to cache the URLs of all open clients

[philipwalton]

Library Affected:
sw-lib

Issue or Feature Request Description:
Add a method to cache the URLs of all open clients

This allows a dev to ensure a site can run offline after the first pageload without having to wait for a subsequent pageload.

Note: we'll probably want to make sure we use the includeUncontrolled option

[jeffposnick]

I'm going to bump down this priority, since it's new functionality that would be nice to have, but not needed for parity with our legacy offerings.

[jeffposnick]

Quick hack for how this might work. It would be code that run in the context of window, and could look like:

async function populateCache(cacheName) {
  const urls = performance.getEntriesByType('resource').map(resource => resource.name);
  const cache = await caches.open(cacheName);
  return Promise.all(urls.map(async url => {
    // Explicitly check to see if the URL is present in any cache, not just in cacheName.
    // Otherwise, we'd end up double-caching URLs that are managed via precaching.
    const alreadyCached = await caches.match(url);
    if (!alreadyCached) {
      try {
        await cache.add(url);
      } catch (error) {
        // Super-hacky.
        try {
          const response = await fetch(new Request(url, {mode: 'no-cors'}));
          await cache.put(url, response);
        } catch (anotherError) {
          console.info(anotherError);
        }
      }
    }
  }));
}

Problems with this strawman approach:

• We should provide some way of filtering what gets cached via a whitelist, blacklist, or both.
• Running this code unconditionally on every page load is a waste, so maybe we should take care of running it inside of a navigator.serviceWorker.oncontrollerchange event listener. But then we might run into issues if our code isn't loaded until after the service worker has been installed, and the controllerchange event has already been fired.
• I don't think we can determine from the underlying Performance API whether a cross-origin resource was loaded with CORS or is opaque, so we might be stuck trying CORS first, and then falling back to no-cors if that fails. Using no-cors unconditionally is another option, but that would end up causing issues for resources that can't be used by the page when they're opaque, and it's also riskier, since you might end up caching error responses.

[jeffposnick]

Related discussion in the service worker specification: w3c/ServiceWorker#1282

[jeffposnick]

This is now doable in v4 via a recipe that uses workbox-window. @philipwalton will be publishing a corresponding guide.