jeffposnick
commented
8 years ago Here's a rough outline of what I was thinking about in terms of developer experience:
/*
Assume that:
- routing.js covers similar ground to sw-toolbox's current Express/RegExp routing, and exposes goog.routing.Route
Route has three properties:
- when: a function that's passed both a URL-wrapper around FetchEvent.request.url, and the raw FetchEvent,
and returns true when this route should handle the request
- options: used to pass additional context to the handler, e.g. name of cache to use.
- handler: a function that's passed the FetchEvent and any options, and returns a Promise which resolves with a Response.
- runtime-caching.js includes the various caching strategies in sw-toolbox, and exposes goog.runtimeCaching.*
- precache.js is the output of a sw-precache-style build process, including a list of assets, along with
the install/activate handlers, and exposes goog.precache.*
*/
importScripts(['routing.js', 'runtime-caching.js', 'precache.js']);
const routes = [
new goog.routing.Route({
when: ({url, event}) => goog.precache.shouldHandle(event),
handler: goog.precache.handler
}),
new goog.routing.Route({
if: ({url, event}) => url.pathname.startsWith('/api/'),
handler: goog.runtimeCaching.staleWhileRevalidate,
}),
new goog.routing.Route({
when: ({url, event}) => url.origin.startsWith('https://imagecdn.com'),
handler: goog.runtimeCaching.cacheFirst,
// See https://github.com/GoogleChrome/sw-helpers/issues/44#issuecomment-250766630
// for discussion of options/configuration.
options: {
cache:{
name: 'images',
maxEntries: 10
}
}
}),
new goog.routing.Route({
when: ({url, event}) => event.request.mode === 'navigate',
handler: ({url, event}) => {
// Implement your own strategy here.
},
}),
];
// Optional helper to add in .catch() to the end of your response chain,
// regardless of which route is chosen.
const catchHandler = ({url, event}) => fetch(event.request);
// Optional helper which is used when nothing else matches.
const defaultHandler = ({url, event}) => {
return caches.match(event.request).then(response => response || fetch(event.request));
}
goog.registerRoutes({routes, catchHandler, defaultHandler});Inside runtime-caching.js, precache.js, we'd take advantage of smaller modules that can handle things like cache expiration and notification of cache updates.
As mentioned in https://github.com/GoogleChrome/sw-precache/issues/147, we're still blocked on sw-precache needing to generate the top-level service worker file in order to properly trigger the service worker update flow. If we wanted to prototype something new, we could do so if we made sure that the filename of the sw-precache output ('precache.js' in the example above) included a hash that was tied to its contents.
Happy to brainstorm more!
gauntface
samertm
addyosmani
NekR
felipenmoura
cc @addyosmani, @jeffposnick
We've chatted a little bit about future of tooling, but it would good to move the discussion a little further forward and agree of a rough plan and then move into some more technical detail and strategy.
This is a bit of a brain dump as to audience we might want to target, followed by general requests / approaches people have hinted at wanting and finally a super vague idea of what we can do.
Audience
Possible audience based on some developers editing a generated SW?
Requests / Approaches
General Architecture
What are the thoughts of these vague topics, is this the general approach people have in their heads? Is a target audience missing? General architecture seem wonk / destined to fail?