Re: [slightlyoff/ServiceWorker] Handling race conditions - API for accessing pending requests? (#959)

@jakearchibald I see what you mean. For the case in #920 though, the SW is spawned exactly to the navigation request, so knowing this, browser may not remove that pre-flight request from `requests` store until SW is destroyed.

For the case of link=preload, yeah, this way requests could be potentially missed, but since SW already controls the scope, it could be handled this way:

_(cache matching added, assuming SW cached request and if it's not inflight -- try to get from cache)_
```js
self.addEventListener('fetch', event => {
  const request = self.requests.match(event.request).then(inflight => {
    return inflight || self.caches.match(event.request) || fetch(event.request);
  });

  event.respondWith(request);
});
```

Also there could be other solution for link=preload right now:

```js
let stylesRequest;

self.addEventListener('fetch', event => {
  const url = new URL(event.request.url);

  if (url.path === '/styles.css') {
    let request;

    if (!stylesRequest) {
      stylesRequest = fetch(event.request).then((res) => {
        stylesRequest = null;
        return res;
      });
    }

    event.respondWith(stylesRequest);
  }
});
```

But this is reliance on a global state which is obviously bad and shouldn't be used, especially we SW team decide to on multiple SW instances.

Just trying to generate some ideas.


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