Of course, different applications have different requirements, especially when it comes to caching. I know that we have talked a lot about caching, but when you think about it, a progressive web app and the whole idea behind the Service Worker is to provide an offline experience for your web applications. Caching is a very big part of that. This is an application to where I would make the argument that we should be caching these pages because it has

This is an application to where I would make the argument that we should be caching these pages because it has valuable information that maybe whoever is out in the field will need to access. If they have gone to one of these pages and then lose connectivity, they should be able to get to that information because maybe they need to report it or something. But I want to cache these pages. But I also want to change them because,

But I want to cache these pages. But I also want to change them because, well, I want an image for each meter. Now, the image isn't really anything spectacular. It's just an image that has the ID of the meter that we are currently looking at. If we go to any one of these pages, we are going to see a different image. The only thing is that if we get more than 10 meters, we're going to have an issue because I only have 10 images.

The only thing is that if we get more than 10 meters, we're going to have an issue because I only have 10 images. But the idea is these are images that could be beneficial to the end user, but they aren't necessary for an offline experience. I want to get away from caching all of the static assets unless if it is part of our shell. Because if it's part of the shell, then it is naturally very important for our application. But if it's not part of the shell and it's not important content,

But if it's not part of the shell and it's not important content, then let's not cache that. Which means that we want to cache these pages without caching the images. So we're going to take this in two steps. Because if we don't cache images, then we need to provide some kind of placeholder to denote that an image is supposed to go here. So we will get there. The first thing that we need to do, however, is cache our pages.

So we will get there. The first thing that we need to do, however, is cache our pages. So that is, of course, going to be inside of our fetch handler. And our service worker is getting a little unruly. So we're going to need to start breaking things out into modules, which we can do. But we will have to register our service worker in a slightly different way. But for right now, we're going to be fine. So that if we are navigating, which means that we are going to a different page, then we want to cache that page. So the first thing let's do is let's open up a cache just for our pages.

then we want to cache that page. So the first thing let's do is let's open up a cache just for our pages. So we can call it page cache or something like that. But of course, this is a string and I am going to mistype a string. So let's create a constant for that instead. So that we'll just call it page cache. It'll have the value of page cache. And then we can use that now. So if we can find where we were, there we are. So if we are navigating, we are going to open up our page cache.

So if we can find where we were, there we are. So if we are navigating, we are going to open up our page cache. And we are still going to try to fetch the request that we are making. But we're going to do this. We will store that with a response and then we will eventually return that response. But of course, we need to be sure that we have an actual response here. So we'll check if it's okay. And I guess it's good to have some guardrails up. So that also if the request URL starts with the origin of the service worker. That way, we would be caching pages that come from our application,

So that also if the request URL starts with the origin of the service worker. That way, we would be caching pages that come from our application, as well as the development server. So this way, we kind of catch everything that we need. And let's see, we want to store this in our cache. But I just want to just set it and forget it. If it works, great. If not, that's fine too. Because if it fails, then we still have our fallback of the offline page or the offline response.

Because if it fails, then we still have our fallback of the offline page or the offline response. So I just want to do this to where we will put the clone of the response for this request. And if it fails, we're just going to catch it and swallow it because we don't care. So that way, we get our response, we cache the response, and then we return the response. Which means though, that if there is some connectivity issues, then we want to try to get the cached page. In which case, we will reach into our cache to match that request.

then we want to try to get the cached page. In which case, we will reach into our cache to match that request. And if we have the cached page, then we will simply return the cached page. Otherwise, we fall back to the offline and things like that. Sounds reasonable. So let's go to the browser. Let's pull up the developer tools and let's unregister our service worker. So that we can do a hard refresh to load the new one. And let's go through the motions here. So we go to our meters page.

And let's go through the motions here. So we go to our meters page. We'll view a few of these. And let's view the first three so that we are loading these into the cache. And then, oops, we are offline. So if we go to any one of these, we've cached these pages. So of course, we are going to see those. But if we go down to one that we haven't viewed, let's say this last one here, we see the offline page. So that functionality is working as we would expect it to be.

let's say this last one here, we see the offline page. So that functionality is working as we would expect it to be. But we are caching the images because it is a static asset and we are caching that. And we don't necessarily want to do that because in this case, it's not necessary. It's not an important thing. So we need to change this a little bit. Before we do that, however, I want to go to the Network tab. And there's gonna be an option to disable cache. And this is important because if you are testing the offline functionality of your Progressive Web App, images and things could be cached just by the browser

And this is important because if you are testing the offline functionality of your Progressive Web App, images and things could be cached just by the browser itself so that it will be loading into the page here even though you don't necessarily want it to, at least as far as development is concerned. In this case, we're gonna use a placeholder here. So we want to see the placeholder. And if the browser itself caches this, then we're not gonna see the placeholder. So I'm going to disable cache here. And that is going to make it so that the browser will not cache those images, and so that we can therefore see our placeholder image.

And that is going to make it so that the browser will not cache those images, and so that we can therefore see our placeholder image. So let's go back. Now, one thing I did off screen, in the previous episode, we used that cache first strategy. Well, I commented that out because I want to use the stale with revalidate here. But we're gonna start to be, well, a little explicit as to what we cache here because we don't want to cache images now. We want the images from our shell, but nothing else. So now what we are going to do is we still want to open up the cache and

We want the images from our shell, but nothing else. So now what we are going to do is we still want to open up the cache and all that stuff. But we want to see if this request is for an image. And we can do that with this destination property. Now, this is on the request, and this is going to give us some different values. For an image, it's gonna be an image. If it's CSS, it's gonna be style. If it's JavaScript, it's gonna be script. So we can start to inspect the kind of request that's being made for

If it's JavaScript, it's gonna be script. So we can start to inspect the kind of request that's being made for whatever asset that is being requested. And we can start to branch our code based upon that. So in the case of an image, we don't want to cache this at all. So it's kind of like what we did with the pages in that all we are going to do is await fetching that request and then sending that back. But it's entirely possible that that fails in the case of some connectivity issues, in which case we would want to display our placeholder. Now, we don't have our placeholder yet.

issues, in which case we would want to display our placeholder. Now, we don't have our placeholder yet. Well, we have the placeholder image, but we aren't caching that as part of our shell or anything like that. So let's open up the pre-cache manifest controller. And we're just gonna add this as part of our shell. It is inside of images, and then placeholder.svg. Placeholder, I've mistyped placeholder before. So, and of course, if you mistype this, then nothing's gonna work. And since it's a string, we are going to create a constant here.

So, and of course, if you mistype this, then nothing's gonna work. And since it's a string, we are going to create a constant here. So image placeholder, and we have our URL there. So now this should be cached as part of our shell, which means that when it comes time to displaying images, if we are online, then great, everything's fine. But if not, then we want to display our placeholder. So we are just going to return await cache match and the image placeholder. But of course, this could fail, or rather it could return nothing, in which case we want to fall back to returning just that response of offline.

But of course, this could fail, or rather it could return nothing, in which case we want to fall back to returning just that response of offline. So there we go. So if it's an image, we aren't caching it anymore. All we are doing is if we are online, we're returning it. Otherwise, we are showing our placeholder, and we are falling back to just being offline there. So we should be able to go back to the browser. Let's unregister our service worker. Let's do a hard refresh.

Let's unregister our service worker. Let's do a hard refresh. So that now this page is cached. We should be able to go to any one of these other pages. Let's go to the first three. And if we go offline, and we click on one of the three that we just accessed, we see our placeholder being used here. So we are no longer caching our images, and we are showing the placeholder wherever an image request fails. So if we had a logo, which we can make the argument that the logo is important,

we are showing the placeholder wherever an image request fails. So if we had a logo, which we can make the argument that the logo is important, that's part of the shell, but let's just imagine the logo isn't. If we were displaying a logo that wasn't cached, then we would also be seeing our placeholder image there. So that's great. So our offline experience is getting more and more user friendly, but we can make it even more user friendly. Because as it currently is, a user doesn't know that they are offline, unless that they try to access a page and they see the offline page.

Because as it currently is, a user doesn't know that they are offline, unless that they try to access a page and they see the offline page. It would be nice to have some kind of indicator to show that, hey, you're offline, and we will look at that in the next episode. And we will look at that in the next episode. And we will look at that in the next episode.