Re: [w3c/ServiceWorker] Declarative routing (#1373)

It might also be useful to describe the default routes you get when a service worker is installed.  Either route to FetchEvent or no where depending on if there is a fetch handler.

> @wanderview: How do you feel about this implementation-wise?

Personal opinion that does not represent any actual implementation priorities:

I guess I'm most interested in how something like this could be incrementally approached.  For example, if we started with:

1. `ServiceWorkerRouter.add()`
2. `RouterIfDate`
3. `RouterSourceNetwork` with default options

Or replace (2) with `RouterIfURL`.  This minimal initial set might unblock certain use cases.  We could then layer additional items later.  I'm not sure how people would feel about a having a partial "router" in the platform that doesn't provide a full routing capability.

To me the `RouterIfDate` is more compelling at the moment because we don't have a good alternative solution for avoiding service worker startup costs in an expired state.  `RouterIfURL` is more "router-like" but it seems oriented at carving out exceptions for certain subresources, but I feel like that is less of a problem since typically service worker startup is not necessary for subresources.

I imagine, though, there is going to be a tension between how many of these options and extensions to implement vs using javascript in FetchEvent.  For example, the list of logical combinations in the "extensibility" section seemed like perhaps something that should just be done in js.  I'm not sure we want to implement and maintain a complex DSL when we can achieve the same thing with js.

-- 
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/1373#issuecomment-451161092