 Hi, my name is Ariana Jara, and today in Unpacking the Workbox, we are going to learn how to create an offline fallback page for your PWA. Having an offline experience is one of the requirements for some browsers to consider your web app installable. While it is possible to create a complete offline experience for your app, there is also the possibility of creating a simple offline page. And with Workbox recipes, you can serve it with as little as one line of code. Before we get into the code, we have to unpack Workbox encapsulation a little bit. So, bear with me. Workbox is a set of tools developed to make the implementation of service workers easier. And within Workbox, we have different levels of encapsulation for implementing a specific task. So, if we compare building an offline page with Workbox to cooking a bowl of pasta, one option could be to cook the pasta and sauce from scratch. That is the equivalent of implementing the fallback with just the service worker API. I'm not going to run through this scenario, but if you want to learn all the basics about service workers, visit this link. Next option, you could buy the pasta ready to cook and add your own sauce. That will be like creating the offline page with the Workbox libraries, which gives us flexibility, but the code can still be repetitive. Or you can go to a restaurant and order the bowl of pasta you want or prepare for you. That would be like using the Workbox recipe. You don't have that much flexibility, but you'll be done with your task with one line of code. Let me show you how to implement options two and three. The fallback page, not the pasta. For the longer version of the offline page fallback, we need two Workbox modules, Workbox routing and Workbox strategies. If you want to check all of the documentation about these modules, check it out here because I'm focusing only on the bits that create an offline fallback. The first step is to create our offline fallback page. The document we are going to serve when the app fails to get the response from the network. This page should be self-contained so that when we cache it, we cache everything that it needs to render. In the code here, we see that we use the install event to ask our service worker to cache that page to use it in the future. To understand more about the install event, you will need to check out the service worker documentation. Next, we create an object called a handler. This handler checks if the app is requesting a document because if the request that failed was for a document, it is then that we want to respond with our fallback page instead. As I was saying, this handler will only run if there is an error making a request. That is what the setCatchHanderLine does. It tells the service worker to use this handler if it errors on the request. This piece of code is better than implementing this behavior with only the service worker. But we can do better. With the Wordbox offline recipe, that same task looks like this. This line of code does everything we described under the hood. You still need to create the fallback document that your app is going to serve. And if you don't pass any options, it will assume that that document is called offline.html. The offline fallback receives a set of options. For example, you can change the name of your offline document and you can also add fallback options for fonts and images. Check out the documentation for more details. It is a good practice and a requirement for PWAs to have an offline page with your app aesthetics and using Wordbox recipe, you can get one with a single line of code. Check out Wordbox documentation for more information on modules and other recipes. You can subscribe for more Google Developer news and tips. Your comments and questions below are welcome. Thank you. Until next time.