Re: [w3c/ServiceWorker] Making a concurrent request for navigations (#920)

Soooooo our API design doesn't really work.

We decided that this setting should have a lifetime associated with the service worker registration, meaning that it must be set per service worker. This reduces the likelihood that it'd be set and forgotten about, leaving (some?) users with double requests on navigations, since the preload is never used.

This worked well with my [pre-F2F proposal](#issuecomment-245621515), but we also decided that the value for the header must be settable at any point. This is at odds with the above idea, because I'm pretty sure developers will want to treat the header as a piece of state that lives beyond the service worker.

Eg: Imagine I'm updating my service worker. I use navigation preloads, and I want to continue using them:

```js
self.addEventListener('install', event => {
  event.waitUntil(
    new Promise(resolve => {
      if (!self.registration.active) {
        resolve();
        return;
      }

      resolve(self.registration.active.getNavigationPreload());
    }).then(settings => {
      settings = settings || {value: 'some-default'};
      return self.registration.installing.setNavigationPreload(settings);
    })
  );
});
```

The above is horrible, and doesn't even work. If the header value is updated at any point while the new service worker is waiting, its initial value will be out of date.

Developers could work around this by calling `setNavigationPreload` on all workers in a registration every time they use it (urgh), or call `setNavigationPreload` in the `activate` event, but by that time the current header setting has gone, so the developer would have to also retain it in indexedDB or whatever.

If allowing the header to be set at any time is a requirement (and Facebook says it is), I think we should just put this on the registration object.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/ServiceWorker/issues/920#issuecomment-251138064

Received on Monday, 3 October 2016 15:29:18 UTC