We've been talking a lot about caching, and we're still gonna. There are primarily three strategies that we can use to cache information, and we have seen two of those. If we check out the code for Episode 4, our service worker was much more simple, but this takes what's called a network-first approach, to where we still make a request, and then we cache the response, but then we return the response back to the client, so that the client always has the most up-to-date information, unless if there's some kind of network connectivity, in which case we try to get the cached response, which hopefully the cached response is, you know, at least has the most up-to-date information as far as the cache is concerned. But this is, of course, very important for applications where you need up-to-date information,

know, at least has the most up-to-date information as far as the cache is concerned. But this is, of course, very important for applications where you need up-to-date information, and obviously there are applications that you would want that. However, I would argue that most applications want you to have up-to-date information, but it's not absolutely vital to have the most up-to-date, which is essentially what we have been doing for the past couple of episodes. We've taken what's called a stale-while-revalidate strategy. In that, let's find the fetch handler. There it is. Okay, so if the request mode is navigation, then we don't cache anything.

There it is. Okay, so if the request mode is navigation, then we don't cache anything. We just return the response from that request, and then we're done. However, when it comes to static assets, we take a completely different approach, and we can see what that approach is down here with our return statement. We are returning the cached response. If that doesn't exist, then we are returning the network response. And of course, if that doesn't exist or if we had an issue there, then we return an offline response. But the stale-with-revalidate strategy is very common.

response. But the stale-with-revalidate strategy is very common. We provide the cached information up front, which is great for performance, but we also revalidate the cache. So with every request for whatever resource that we are making a request for, we provide the cached response, but then we cache the most up-to-date response from that request. So we are always revalidating the cache, but providing stale content. In most cases, that's fine. But then there are some applications where even having the most up-to-date or having slightly less up-to-date information really isn't important.

But then there are some applications where even having the most up-to-date or having slightly less up-to-date information really isn't important. What is most important is having instant performance, especially if the content isn't going to change very often, like static assets. But there could be pages that just aren't changed very often, in which case you could provide a cached version of that. So it's a cache-first approach. And we are gonna modify our service worker to use a cache-first approach. But first, I want to essentially extract this functionality right here. Because this is primarily where we use that stale with revalidate.

But first, I want to essentially extract this functionality right here. Because this is primarily where we use that stale with revalidate. We provide the stale cached information. We also cache the response so that we refresh that cache and so on. So I wanna break this out so that we essentially return await and then stale with revalidate. But we need two things. We need the request and we need the shell name there so that we know what cache to use. So let's just write that function,

that we know what cache to use. So let's just write that function, which I'm gonna put at the end of our function list because it's alphabetical. So this is async function and stale with revalidate. We have the request, we have the shell name, and then all we really have to do is just paste in that code and make it look pretty. Of course, we could write this a little bit differently so that it's a little easier to understand, which I think we could definitely do with the cache-first. So we will write an async function called cache-first.

which I think we could definitely do with the cache-first. So we will write an async function called cache-first. We need essentially the same information, the request and the shell name because we still need to work with those. I'm gonna paste in that code because really, what do we wanna do? First of all, try to open the cache for our shell name. We get the cached response, and then we will check. If we have something in the cache for this request, then we will just return the cached request, that cache-first strategy. And then from there, we just need to make a request for whatever was requested so

then we will just return the cached request, that cache-first strategy. And then from there, we just need to make a request for whatever was requested so that we can get the response and then cache that so that we can serve the cache going forward. In which case, we'll have a try and a catch. And this is gonna start, well, it's gonna be practically the same thing. But we're gonna write it so that it's a little bit easier to read, so that we will have our response equals await fetch. And then we will pass in the request. Except let's not call it response, let's call it res because that's what we used

And then we will pass in the request. Except let's not call it response, let's call it res because that's what we used here, and then I'm just gonna take this if statement. Because we still want to check if the request is okay, or I'm sorry, if the response is okay. And if the response is essentially from our origin, or if it's from cores, or of course, if it is app.css, then we want to cache that information. So that we can then return that response. Otherwise, there's nothing to return except an offline response. Because there was some kind of issue as we were fetching our request,

Otherwise, there's nothing to return except an offline response. Because there was some kind of issue as we were fetching our request, or caching the response, or anything like that. So there we go, we have our cache first. So now that we have this as a function, we can just use that function back down inside of our fetch handler, which is all the way down here. And tell you what, let's comment that out, so that we can just paste that. And then we will call cache first there. So there we go.

And then we will call cache first there. So there we go. Now, of course, the cache first strategy is really going to depend upon your application, really any one of these strategies is going to depend upon your application's needs. But especially when it comes to static assets, or assets that aren't going to change very often. Then the cache first is really going to work very well. Which in this particular case would work, because these are primarily static assets.

Which in this particular case would work, because these are primarily static assets. The only thing would be the CSS coming from our dev server, because that would probably change a lot. In which case, it makes much more sense to use the stale while revalidate strategy. Now, as I'm looking at this, I don't think, Did I talk about why we're just returning a response here as opposed to returning the offline and it's because these are assets. This isn't something that we are navigating to, it's not a page or anything like that, these are assets.

This isn't something that we are navigating to, it's not a page or anything like that, these are assets. So, images, CSS, JavaScript, those kinds of things, it just makes sense to return a response in that particular case. But when it comes to images, it would be very useful to have some kind of fallback image that we could use, kind of like the offline page that we have. But it would be used for images, and that is something that we can do in the next episode.