way to have the progress bar while service worker is doing its magic

[novaknole]

Library Affected:
workbox-sw, workbox-build, etc.

Hi @jeffposnick

I am looking for a graceful way to show a progress bar while service worker is doing its precache. (This essentially means - while service worker is installing)...

The way I handle/Solve this now: Right now, What I do is put workbox's generated manifest in my app.js file too and loop through this there , making requests for them and having the progress bar . After i make requests for all the assets present in manifest, Then i register service worker which essentially starts installing. As soon as I register my service worker, I remove progress bar and service worker runs in background (because I already made requests for manifest entries in my app.js , service worker doing the same thing will get those assets from http cache) and this is how I have my app.
When user enters the site for 1st time, we say: installing app. If user enters the site for 2nd time, we say loading app. If code updated and user clicked download new version button, we say updating app.

The way I want to have: I am thinking of removing looping through manifest and making requests for them in my app.js file. and only have the assets downloaded in service worker's install event. I also want to have installing, updating, loading words below progress bar.

I found : https://developers.google.com/web/tools/workbox/guides/using-plugins . On this link, there's custom plugins and we have different hooks (cacheDidUpdate and many others).

To even start addressing this problem, we will need to know when:

• precaching starts. (first event which gets called only once at the beginning)
• even though we have different hooks(cacheDidUpdate, cacheWillUpdate, cacheKeyWillBeUsed, many others), still couldn't find the correlation between these events to accomplish what I want. Some of them might break something as I am using different cache strategies in my service worker and who knows what it will break... One of the actual thing is if user enters the site for 2nd time, cacheDidUpdate or cacheWillUpdate won't get called. cachedResponseWillBeUsed might get called - maybe.

Have you thought about this problem and if there's anyone who has a working demo or maybe can confirm that it's doable with these hooks?

[jeffposnick]

Writing a cacheDidUpdate plugin, and calling addPlugins() should be sufficient to accomplish what you describe. You can associate your custom plugin with just the act of precaching so that it won't be called during any other activities inside the service worker.

There's a plan for Workbox v6 to make this interface feel more like associating a plugin with any other strategy, instead of having to call the precaching-specific addPlugins() method: #2459

I don't personally have an example to share of using a cacheDidUpdate plugin long with precaching, but like I said, it should work.

[novaknole]

@jeffposnick

Q1) I guess if I import addPlugins from workbox-precaching , its cacheDidUpdate will only get called while precaching. So the problem(making sure it's not gonna interfere with some other caching strategies for runtime) is not even there . Right?

Q2) Let's say i have 5 items in a manifest. So when user first enters the website, cacheDidUpdate will get called 5 times. In this, I can use postMessage to give a tab a message to say that entry has been added so you're good to move your progress bar by 1*100/5. Let's say that I changed some code and deployed new version. Right now, I use a custom banner to notify the user that a new version is available.. if he clicks, that's when new service worker gets in control via the help of skipWaiting. When he clicks on that banner, I tell user the message on the progress bar updating app. But with this cacheDidUpdate , This seems impossible since cacheDidUpdate gets called before user clicks on that banner .. Does this make sense? looks like I can't achieve exactly the same scenario as I have right now? Let me know if you want me to explain it in more details...

[jeffposnick]

1. Right.

2. Right, cacheDidUpdate is called for each updated URL in your precache manifest while your updated service worker is in the installing state. Your logic around showing a banner and asking the user to activate the new service worker is likely tied to the service worker being in the waiting state, which will happen after installing.