Create a Progressive Web App with React and Register a Service Worker
A Progressive Web App (PWA) can cache static assets, which allows an app to be rendered faster, and even allows it to operate offline!
We’ll start a new app with create-react-app, and enable the service worker by registering it in index.js. Then we’ll build and serve a production version of the app - and show that it can work offline by disabling the server and refreshing the tab.
Instructor: [00:00] Create a new app with Create React App, called Todo PWA. Then CD into the new directory and start the app with yarn start, which will automatically bring up the app in a new web browser.
[00:19] I have a basic web server prepared, which includes a simple express app that can serve a list of to-do items, allows you to make a new item and also to delete an item from the list. That is running on localhost port 4567.
[00:43] For the React app itself, I added Bootstrap, which will come from a CDN, and have put the entire to-do list app in app.js. In the browser, we have a working, regular to-do list app. This is just a regular web app so far.
[01:05] A progressive web app is enabled by a service worker, which we can see in index.js. Old versions of Create React App turned on the service worker by default. Starting with Create React App 2.0we have to manually enable the service worker by calling serviceWorker.register.
[01:23] By default, that uses a cache-first strategy to serve all of our assets generated by the react app. If we open serviceworker.js, we can look at the register function that we just called.
[01:36] One really important thing to notice is that the service worker only registers in production mode. You could change this file to work in dev mode too, but that's advised against in the documentation because of caching problems that can be frustrating during development.
[01:51] If you do decide to go that route, you'll also need to change the default serviceworker.js file name because of a default serviceworker.js file that is served from React scripts in development mode.
[02:04] Instead, we'll test the service worker by building a production version of the app with yarn build and then serve that production version with serve -s build and then open localhost port 5000, where we can see the app running.
[02:24] Since we've registered the service worker, if we refresh now and open the Chrome DevTools to the console, we can see the message from Workbox showing us that the pre-cache is responding to the static assets.
[02:39] In the Network tab, we can see that the JavaScript and SVG assets are all being served now by the service worker instead of by the dev server. Since they come directly from the cache, your entire app will load faster than if it required a network call for each of those assets, which is one of the primary benefits of registering the service worker.
[02:59] In fact, we can now actually turn off the app server. If we refresh the app in the browser, we can still see it. There's nothing serving on localhost port 5000, but the app still loads because the service worker has been registered and is serving a cached version of the production app assets.
[03:18] Notice though that the service worker is only serving the static assets. The to-do items are still being loaded from the network, from our express web server. If we turn that off as well and refresh now, the list of items won't load because it's still trying to make a network call for that.
[03:38] The default service worker implementation from Create React App will cache all the static assets, but not any of the dynamic network calls that your app makes.