Make it possible to use router logic outside of a fetch handler

[philipwalton]

Library Affected:
workbox-routing

Similar to the issue brought up in #1395 by @jeffposnick, it's difficult to take advantage of Router functionality outside of a FetchEvent handler.

Use case

The use case is having a list of URLs that you want to cache exactly as if they were real requests from the client. E.g. the list of URLs requested from the window (via the ResourceTiming API) prior to the service worker being activated.

If you've already written logic to match routes and strategies to URLs and put that logic in a router, it's unfortunate that you can't reuse any of it if all you have is a URL (or a Request instance).

Possible solutions

When looking at the Router#handleRequest() method, it requires an event object, but AFAICT it does actually need an event object to work. It seems like the main reason it takes an event is to pass it off to the strategies, which may then need to call event.waitUntil().

We could update the handleRequest() method to accept a url or a Request object (in addition to an event).

Alternatively, we could add an additional method that just returns the first registered route matching a request from a router (similar to what _findHandlerAndParams() does, but preferably in a way that doesn't require a dev to handle params in cases where they don't apply).

That way the developer could do:

for (const url of urlListFromWindow) {
  const request = new Request(url);
  const route = router.matchRequest(request);
  
  await route.handler.makeRequest({request});
}

[jeffposnick]

When looking at the Router#handleRequest() method, it requires an event object, but AFAICT it does actually need an event object to work. It seems like the main reason it takes an event is to pass it off to the strategies, which may then need to call event.waitUntil().

Right, allowing strategies to call event.waitUntil() is the main motivation for requiring a FetchEvent, if I recall.

Alternatively, we could add an additional method that just returns the first registered route matching a request from a router (similar to what _findHandlerAndParams() does, but preferably in a way that doesn't require a dev to handle params in cases where they don't apply).

That sounds fairly clean, and in line with what we did with makeRequest(). 👍