richardkazuomiller
commented
5 years ago @jakearchibald
We could also add things like { url: { pathStartsWith: '/foo/' } } to match against particular components of the URL, but you'd be matching against all origins unless you specify otherwise.
I think that's fine because sometimes we care about checking the domain and we don't at other times. Here's some code that's more-or-less exactly what I'm doing on a real-world service worker.
self.addEventListener('fetch', function(event) {
const request = event.request;
event.respondWith(
caches.match(request)
.then(function(response) {
if (response) {
return response;
}
const url = new URL(request);
if(url.pathname == '/some_path') {
const redirectUrl = new URL(url.href);
redirectUrl.pathname = '/';
return Response.redirect(redirectUrl.href,302);
}
if(url.hostname == IMAGE_CDN_HOSTNAME) {
return fetchFromImageCdn(request);
}
return fetch(request);
})
);
});
function fetchFromImageCdn (request) {
// basically fetch once and cache forever
}Technically, both https://mywebsite.foo/some_path and https://myimagecdn.foo/some_path will both redirect to /, but I know that the page will never try to access https://myimagecdn.foo/some_path so it's fine that both match.
I'd like to use declarative routing to do something like this
// Things that try the cache, then go to the network
const cacheThenNetwork = [RouterSource.cache(), RouterSource.network()];
// These paths match all domains, but I'm only using one so it's fine
router.get(RouterCondition.url.pathname.is('/'), cacheThenNetwork)
router.get(RouterCondition.url.pathname.startsWith('/static/'), cacheThenNetwork)
// Any path on the image CDN
router.get(RouterCondition.url.hostname.is(MY_IMAGE_CDN), cacheThenNetwork)
// fetch event listener can now be simplified
self.addEventListener('fetch', function(event) {
const request = event.request;
const url = new URL(request.url);
if(url.pathname == '/some_path') {
const redirectUrl = new URL(url.href);
redirectUrl.pathname = '/';
event.respondWith(Response.redirect(redirectUrl.href,302));
}
});
jakearchibald
WORMSS
bkardell
Siilwyn
jeremy-coleman
asakusuma
ylafon
n8schloss
mgiuca
fallaciousreasoning
yoshisatoyanagisawa
webmaxru
sisidovski
domenic
ErikWitt
quasi-mod
Here are the requirements I'm working towards:
I'm going to start with static routes, and provide additional ideas in follow-up posts.
The aim is to allow the developer to declaratively express a series of steps the browser should perform in attempt to get a response.
The rest of this post is superseded by the second draft
Creating a route
WebIDL
JavaScript
The browser will consider routes in the order declared, and will consider route items in the order they're given.
Route items
Route items fall into two categories:
Sources
WebIDL
These interfaces don't currently have attributes, but they could have attributes that reflect the options/defaults passed into the constructor.
Conditions
WebIDL
Again, these interfaces don't have attributes, but they could reflect the options/defaults passed into the constructor.
Shortcuts
GET requests are the most common type of request to provide specific routing for.
WebIDL
Where the JavaScript implementation is roughly:
We may also consider treating strings as URL matchers.
router.add('/foo/')===router.add(new RouterIfURL('/foo/')).router.add('/foo/*')===router.add(new RouterIfURLPrefix('/foo/')).router.add('*.png')===router.add(new RouterIfURLSuffix('.png')).Examples
Bypassing the service worker for particular resources
JavaScript
Offline-first
JavaScript
Online-first
JavaScript
Processing
This is very rough prose, but hopefully it explains the order of things.
A service worker has routes. The routes do not belong to the registration, so a new empty service worker will have no defined routes, even if the previous service worker defined many.
A route has items.
To create a new route containing items
Handling a fetch
These steps will come before handling navigation preload, meaning no preload will be made if a route handles the request.
request is the request being made.
RouterIfMethod, then:RouterIfURL, then:RouterSourceNetwork, then:RouterSourceCache, then:RouterSourceFetchEvent, then:Extensibility
I can imagine things like:
RouterOr(...conditionalItems)– True if any of the conditional items are true.RouterNot(condition)– Inverts a condition.RouterIfResponse(options)– Right now, a response is returned immediately once one is found. However, the route could continue, skipping sources, but processing conditions. This condition could check the response and break the route if it doesn't match. Along with a way to discard any selected response, you could discard responses that didn't have an ok status.RouterCacheResponse(cacheName)– If a response has been found, add it to a cache.RouterCloneRequest()– It feels likeRouterSourceNetworkwould consume requests, so if you need to do additional processing, this could clone the request.But these could arrive much later. Some of the things in the main proposal may also be considered "v2".