- From: Jake Archibald <notifications@github.com>
- Date: Fri, 15 Sep 2017 07:49:54 -0700
- To: w3c/ServiceWorker <ServiceWorker@noreply.github.com>
- Cc: Subscribed <subscribed@noreply.github.com>
Received on Friday, 15 September 2017 14:50:17 UTC
My aim with this stuff is to try and reduce the amount of independently-set state as much as possible. This means if you update your call to `.register`, your registration will have those settings. My worry with something like `reg.updateViaCache('all')`, is that removing that line leaves users with whatever their current setting is. Whereas removing it from `.register` resets them to the default. I wanted to do something similar with navigation preload, where you'd have to declare it per service worker instance (in the install or activate event), but we lost the ability to do that when we gained additional state – [the header value](https://w3c.github.io/ServiceWorker/#service-worker-registration-navigation-preload-header-value). The service worker registration object is already "live", as `reg.active`, `reg.waiting` and `reg.active` update. It'd be really confusing if we then add some objects that are snapshots. When the registration changes, we already update registration objects if it results in a new `.installing`. Is it a big problem for performance/implementation to update `reg. updateViaCache` in a similar way? If so, I'm happy to look at a `getState` solution, like we do with navigation preload. -- 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/1189#issuecomment-329804737
Received on Friday, 15 September 2017 14:50:17 UTC