![]() The update forced by "Update on reload" is an ordinary one. This is not necessarily what we want in production to happen, but it could save us some time and inconvenience at the development time. It's like we'd implement a call to skipWaiting() as a part of the new Service Worker's install handler, asking it to forcefully take over all the clients. And especially in the development, it's rather annoying that the Service Worker we expect to be running might either be unnoticed by the browser yet or it might be idly waiting for its moment to activate and we might be spending our time uselessly debugging the outdated version of our code.īy checking "Update on reload" we effectively ask our browser to unconditionally check if there's a new Service Worker version available and if so, we ask that new Service Worker to skipWaiting immediately after it gets installed without the need to close the tabs or go through the standard update flow. Both options has its downsides and implementing the full and bullet-proof update flow for the Service Worker is tricky. Also, activating the new version of the Service Worker after it was deployed over the old one requires one of the two things to happen: either closing all the tabs of the application (or hard-refreshing them), so that the number of the previous Service Worker's clients fall down to 0 and it can safely be disposed, or calling self.skipWaiting() by the newly installed Service Worker, in case it's OK to take over the existing clients in the middle of their lifetime. Normally, when the switch is off (or when there's no Dev Tools opened), browsers have its rules how often to check for the new version – Chrome doesn't do that more often than once a day. It alters the rule when the browser checks for the new Service Worker version and when that new version is activated, in case it was found. "Update on reload" checkbox is definitely less self-describing. When to switch it ON? When testing the offline state caches and behaviors of our Progressive Web App. Chrome's Network tab "Disable cache' switch, equivalent to Application tab "Offline" switchĪll the requests will fail to reach the network, so their Promises will get rejected without creating the Response object. ![]() It is equivalent to setting the network emulation to Offline in the Network tab - both do exactly the same and both are issuing a yellow warning badge to save us from unnecessary debugging when we forgot we turned this feature on. By checking it we simulate the lack of internet connectivity from our tab, causing all the network requests to fail and letting us test our offline behaviors. ![]() ![]() Google Chrome's Dev Tools Application tab switches "Offline" switch There's also a separate page for Service Worker inspection, and this is where we're going to have a closer look at the three small checkboxes at the top. This tab offers the ability to inspect and clear the data in all the available storage types (Local Storage, Session Storage, IndexedDB, obsolete Web SQL, Cookies and Cache API) as well as to trace background services' activity (including Background Fetch, Background Sync, Notifications, Push API and Payments. Chrome's Dev Tools has a whole Application tab dedicated to PWA-related matters. Google Chrome, as expected from the Service Worker API and whole Progressive Web Apps ideas main proponent, offers probably the richest developer tooling to ease the debugging, testing and experimenting with the APIs.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |