Progressive Web Apps By Example: Part 2

We dig into service worker events and how to use them.

This article is part of the series that starts with Progressive Web Apps By Example: Part 1.

Service Worker Events

Service workers emit a number of events. Create React App exposes two of them by calling callbacks provided to the exported register function:

• onSuccess: Content is cached for offline use
• onUpdate: New content is available and will be used when all tabs for this page are closed. See https://bit.ly/CRA-PWA

We modify our React application to display these statuses; src/index.js:

and update src/App.js:

We publish the changes to GitHub pages. The first time one loads the application in a browser, it will display the “Content is cached…” message.

Later, after we publish a new version, close the tab, and load the application, it will display the “New content…” message.

Finally, by closing the tab and loading the application it will load the updated version.

Observations:

• Simply refreshing the page will not load the updated application
• Chrome iOS browser does support service workers; however the events are not triggered; Safari browser does work as expected. Weird
• As expected Chrome Android browser does work as expected

Thoughts on Using the onUpdate Callback

Awhile ago, I wrote a number of applications that use an older, now deprecated, mechanism for building offline applications: HTML5 Application Cache. In doing so, I would often implement a particular a pattern that is also applicable to applications using a service worker.

First, I would make sure to simultaneously publish a new version of the application whenever the supporting APIs were changed.

When the application first loads, it would load an API that specifies the API version.

The application would use the success / failure of this call to determine if it was online / offline. In offline mode, the application often had a limited feature set.

When online, the application would compare its supported API version against the API version. If there was a match, the application would operate normally.

If there was not a match, the application would be in a disabled state with a message that the browser was downloading a new version of the application.

The application would then wait for a callback, much like the onUpdate, to provide a message that it was time to close and reopen the tab to load the new version.

note: In writing this, I thought of another edge case that one would likely want to handle. Specifically, handling the situation were the API changes while the application is loaded.

Next Steps

So far we have focused on caching the application and resources for offline use. In the next article, Progressive Web Apps By Example: Part 3 we will explore caching data for offline use.