Add a workbox-window package #1827
Conversation
philipwalton
force-pushed
the
workbox-window
branch
from
6992a48 to
9dc95c5
Compare
|
Ok, I think I've addressed all your comments. PTAL. |
PR-Bot Size PluginChanged File Sizes
New Files
All File SizesView Table
Workbox Aggregate Size Plugin9.86KB gzip'ed (66% of limit) |
|
A |
|
I noticed while testing that the |
@frlinw originally, my design doc did have a And that would lead to situations like this, where some code in a function would never run: const wb = new Workbox('sw.js');
wb.register();
await wb.controlling;
// This message will not get sent on any pageload after the first one.
wb.messageSW({...});Alternatively, the above problem could be solved if the controlled promise resolved on all page loads, but then you'd lose the ability to do something when the SW is first controlling the page. So, I guess that main question is: do you have a use case for needing to await a SW controlling the page on all page loads? If so, can you elaborate? |
@jadjoubran yes, please do! |
@philipwalton what do you think about that ? function controlled () {
return new Promise((resolve) => {
// resolve immediately if a service worker is already in control (every page loads after the first one)
if (navigator.serviceWorker.controller) {
return resolve()
}
// Or wait for the service worker to be in control (first page load)
const controllerChangeHandler = (event) => {
navigator.serviceWorker.removeEventListener('controllerchange', controllerChangeHandler)
resolve()
}
navigator.serviceWorker.addEventListener('controllerchange', controllerChangeHandler)
})
}A variation (I didn't test it) async function doSomethingOnFirstInstallation(something) {
if (navigator.serviceWorker.controller) {
return
}
const controllerChangeHandler = (event) => {
navigator.serviceWorker.removeEventListener('controllerchange', controllerChangeHandler)
something()
}
navigator.serviceWorker.addEventListener('controllerchange', controllerChangeHandler)
})
}My use case:
|
|
Correct me if I'm wrong, but from your use cases, it sounds like you're primarily interested in knowing when a SW is in control the very first time. It doesn't sound like you're wanting to run any code every page load that a particular SW is in control over the page. To do that in const wb = new Workbox('sw.js');
await wb.register();
wb.addEventListener('controlling', () => {
// Run code as soon as the registered SW is in control of the page.
// On subsequent page loads, this event handler will never run.
});
// Do other SW stuff here...If we make this a const wb = new Workbox('sw.js');
await wb.register();
wb.controlling.then(() => {
// Run code as soon as the registered SW is in control of the page.
// On subsequent page loads, this event handler will never run.
});
// Do other SW stuff here...The only benefit I see to a promise is:
|
|
Consider a web app (SPA) which requires some data relative to its global context (translation map, select list, w/e). These data are requested on every page load. |
Sure, but consider all cases after the first time a user installs a SW for your origin (which most of the future of the web will entail). In these cases a I think the 99% use case is: And in my experience, you only need a callback for that once it starts controlling. Future page loads can assume that the controlling code already ran (either via a previous page load, or via the SW's Am I'm ignoring another use case? |
Yes, if I need the new one, I can handle service worker update and force a reload (or ask the user)
I don't know :( still waiting for a 1%-man to decrease the 99% use case to 98%! Just kidding, you are probably right about the 99% use case but I'm sure workbox-window ambition is not to abstract 10 loc of a basic "register & check update" |
This PR is an initial implementation of the
workbox-windowproposal.Most of the implementation is purely additive, but a few things have changed in the build process. Mainly, an additional
build-window-packagesgulp task has been added that buildsworkbox-windowsince its build format is ES modules rather than IIFEs and browser globals.I've also added a new
templatesroute, that allow me to render content dynamically via nunjucks if the route matches the pattern*.tmp.*. This is how I test dynamic SW updates for scripts with the same URL in my integration tests.R: @jeffposnick