Importing ServiceWorkerModule into your AppModule doesn't just register the service worker, it also provides a few services you can use to interact with the service worker and control the caching of your app.
A basic understanding of the following:
\n\nSwUpdate servicelinkThe SwUpdate service gives you access to events that indicate when the service worker has discovered an available update for your app or when it has activated such an update—meaning it is now serving content from that update to your app.
The SwUpdate service supports four separate operations:
The two update events, available and activated, are Observable properties of SwUpdate:
You can use these events to notify the user of a pending update or to refresh their pages when the code they are running is out of date.
\nIt's possible to ask the service worker to check if any updates have been deployed to the server.\nThe service worker checks for updates during initialization and on each navigation request—that is, when the user navigates from a different address to your app.\nHowever, you might choose to manually check for updates if you have a site that changes frequently or want updates to happen on a schedule.
\nDo this with the checkForUpdate() method:
This method returns a Promise which indicates that the update check has completed successfully, though it does not indicate whether an update was discovered as a result of the check. Even if one is found, the service worker must still successfully download the changed files, which can fail. If successful, the available event will indicate availability of a new version of the app.
In order to avoid negatively affecting the initial rendering of the page, ServiceWorkerModule waits for up to 30 seconds by default for the app to stabilize, before registering the ServiceWorker script.\nConstantly polling for updates, for example, with setInterval() or RxJS' interval(), will prevent the app from stabilizing and the ServiceWorker script will not be registered with the browser until the 30 seconds upper limit is reached.
Note that this is true for any kind of polling done by your application.\nCheck the isStable documentation for more information.
\nYou can avoid that delay by waiting for the app to stabilize first, before starting to poll for updates, as shown in the example above.\nAlternatively, you might want to define a different registration strategy for the ServiceWorker.
\nIf the current tab needs to be updated to the latest app version immediately, it can ask to do so with the activateUpdate() method:
Calling activateUpdate() without reloading the page could break lazy-loading in a currently running app, especially if the lazy-loaded chunks use filenames with hashes, which change every version.\nTherefore, it is recommended to reload the page once the promise returned by activateUpdate() is resolved.
In some cases, the version of the app used by the service worker to serve a client might be in a broken state that cannot be recovered from without a full page reload.
\nFor example, imagine the following scenario:
\nindex.html, main.<main-hash-1>.js and lazy-chunk.<lazy-hash-1>.js.index.html, main.<main-hash-2>.js and lazy-chunk.<lazy-hash-2>.js (note that the hashes are different now, because the content of the files has changed).\nThe old version is no longer available on the server.lazy-chunk.<lazy-hash-1>.js from its cache.\nBrowsers may decide to evict specific (or all) resources from a cache in order to reclaim disk space.index.html and main.<main-hash-1>.js).lazy-chunk.<lazy-hash-1>.js.lazy-chunk.<lazy-hash-2>.js from the newer version).In the above scenario, the service worker is not able to serve an asset that would normally be cached.\nThat particular app version is broken and there is no way to fix the state of the client without reloading the page.\nIn such cases, the service worker notifies the client by sending an UnrecoverableStateEvent event.\nYou can subscribe to SwUpdate#unrecoverable to be notified and handle these errors.
You may also be interested in the following:
\n\n\n \n