Most examples of registering a Service worker do so through JavaScript. For example (From MDN):
if ('serviceWorker' in navigator) {
navigator.serviceWorker.register('service-worker.js', {
scope: './'
}).then(function (registration) {
var serviceWorker;
if (registration.installing) {
serviceWorker = registration.installing;
document.querySelector('#kind').textContent = 'installing';
} else if (registration.waiting) {
serviceWorker = registration.waiting;
document.querySelector('#kind').textContent = 'waiting';
} else if (registration.active) {
serviceWorker = registration.active;
document.querySelector('#kind').textContent = 'active';
}
if (serviceWorker) {
// logState(serviceWorker.state);
serviceWorker.addEventListener('statechange', function (e) {
// logState(e.target.state);
});
}
}).catch (function (error) {
// Something went wrong during registration. The service-worker.js file
// might be unavailable or contain a syntax error.
});
} else {
// The current browser doesn't support service workers.
}
But I noticed in the Web App Manifest standard that there is a serviceworker member:
"serviceworker": {
"src": "sw.js",
"scope": "/",
"update_via_cache": "none"
}
This is the only place I've seen this referred to.
This raises two questions for me:
The declarative benefit of the manifest approach is obvious, but if I use that approach, how do I reference the registration object in order to track events similar to the script approach? (installing | waiting | active | failed).
Assuming it IS possible to reference the registration object appropriately, can it miss events? Such as finish installing before I could register an event listener to it.
Since the manifest would be saved in the offline cache, and this manifest would reference the service-worker script, what are the cache implications? Does the 24 hour rule still apply assuming I do NOT store the script in the offline cache? The update_via_cache member is not a simple thing to read in the spec.
It looks like it was added to the spec back in October of 2016, and there is some background discussion in the issue tracker.
My interpretation is that the use case is providing service worker bootstrapping metadata that is relevant when installing a web app via a non-browser mechanism, e.g. via an app store. I don't see any mention of that field in the guidance about Microsoft Store ingestion, though.
So... as of right now, I am not clear that any browsers honor the serviceworker field in the web app manifest, and if your concern is having a functional service worker registration for "browser" use cases, do it using JavaScript.
Your best bet for follow ups would be to ask on the web app manifest's GitHub issue tracker.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With