7 days of WordPress plugins, themes & templates - for free!* Unlimited asset downloads! Start 7-Day Free Trial

Next lesson playing in 5 seconds

  • Overview
  • Transcript

3.4 Working With Multiple Caches

Not everything is created equal when caching, and it makes sense to have multiple types of caches. You'll learn how you can work with multiple caches in this lesson.

3.4 Working With Multiple Caches

We need to rethink our caching strategy because right now we are using a cache first strategy, which means that we always respond with the cache. So it doesn't matter if it's static or dynamic. We are returning it from our cache. And that's not good for our dynamic resources. Now for things like our vendor resources like Bootstrap and Alpine, that's fine. Now you can make the argument that index.html and app.js are a little more dynamic and we don't need to always return them from cache. But definitely our data needs to be fresh. If we are online, we need to make a request and we need to get a response from the server. Now we still need to cache that response so that if we are offline we can still display that information. But if we are online, we should always make fresh requests. So that's going to force us to change the way that we cache our data. And we will essentially have two caches, we will have a static cache and dynamic cache. So the first thing I'm going to do is create some variables for the names of our caches. And the first thing is going to be a version number. Now keep in mind that while we will hand right our service worker, there are some things that are going to be automated. Like if we're using some kind of build process or we're using view CLR or something that is going to build our application. This version number would be automated for us, so that it would be part of the build process. And so every time that we rebuilt our application, the new service worker would be created and we would have a different version for our cache. But we don't have that, we are going to be doing that all manually which is kind of a pain but that's just what we have, but this way we can learn a little bit about handling different versions of cache. So we have old version, the next thing we'll have is a static cache name and I'm gonna set this to just static-v. And then we will incorporate our version number and then we will essentially do the same thing for our dynamic cache name. So we'll just copy and paste and make the necessary changes. So we also need to change our precache, right now it's just an array of URLs. Well, that's not really gonna cut it because we now have multiple types of caches. So we could still have an array but it would be an array of objects so that we can have one object with a name of a static cache name. And then the URLs for that cache could be whatever we need to and I'm going to use everything but our data URL. If we ever decide to change it so that's our index and our app.js files are dynamic, then we can easily do that. Now for our second object, we will have a name to our dynamic cache name, and then of course, we will have a URLs array that has our data.json. So that is the shape of our new cache array. And because we changed the shape here, we do need to address that inside of the install event listener, because this is just not gonna cut it. But it still should be relatively simple. I mean, we could come in and we could hard code it here's the cache for our static. Here's the cache for our dynamic, but if we ever decide to have multiple other objects, then we would have to hard code those as well then I would just like to write it so that if we add anything, it's just gonna automatically work. So what we could do is since we have an array, we could essentially map this array into a bunch of promises. In fact, I'm gonna call it an add all promise, because for each one of these objects, we need to open up the cache with the given name, then we need to add all of the URLs for that cache. So we're gonna use promise all and we are going to map our pre cache so that we can open up the provided cache with the obj.name. And in fact, let's put this on a different line just to kinda make things a little bit easier to read. And then once we have that cache, we will add all of the objects URLs. And that should work just fine. Now of course, we need to do that to inside of wait until so let's just copy that. And that should work just fine, maybe, well, we will see, for sure. So let's get rid of this old code. And let's save it, let's go to the browser, and let's see what we get. So there we go, we can see that we have static and we have dynamic, although our static still says data.json. So let's clear out the storage, let's do a hard refresh and then we can look back at our cache. And there we go, our static is just the static assets, our dynamic is just the dynamic, so great. We got that working. So let's change the version number. And let's go back to the browser. And let's see what happens. So now we have two sets of cache. We have v1 and then we have v2. So whenever we have a new version, we really need to clean up the cache for the old version. And we can do that almost kind of exactly how we set up the cache to begin with. So let's write another asynchronous function that's going to do that. So we'll just call this clearOldCache. And what we will do is provide the names of our current cache, which is inside of pre cache. So this is going to have a parameter we'll just call this keys to keep and we will iterate over all of the caches inside of our cache object, and we can do that, first of all, by getting all of the keys. So we will use our caches object, and we will get all of the keys. And then we can iterate over all of those. But of course, we need a promise to do that. Or at least we need to return a promise. So here, we'll have our keys from the cache. And we want to filter out only those that are not in our keys to keep. So, we will have keys to keep and we'll use indexOf. We'll pass in the key and if it's equal to -1, that means that it is not one that we want to keep because it's not in the keys to keep. So we will call map so that we can delete that key from the cache. And so now that we have this function, we just need to know where to do that. Well, we could do that inside of install, but we are setting up the cache there. And I don't want to cause any problems which could occur. Now there is another event that we can hook into called activate. So after a service worker is installed, it has to be activated before it is well active and usable. So this is actually the perfect place to clear out the old cache. And we want to wait until we will call the clearOldCache function. We will pass in the keys of our pre cache. So let's map to get the names of those objects and that should work. So let's give it a try. Let's go back to the browser. Let's, do a hard refresh and let's see what happens. All right, so first of all, we have an encode reference error cache is not defined, that's on line 47. So let's look at line 47. And yeah, it's not cache, it's caches. All right, so now let's do a hard refresh. And let's see what happens. Okay, our v2s are there v1 is gone. So let's change it to version number 3, and let's just automatically refresh here. Let's see what happens. We still have v1 or not v1, we still have v2, and v3. Now, you might think that's okay, we have an error somewhere. No we don't. Our new service worker is not activated. If we go to the service workers little tab here, we can see that our next version is waiting to activate. And if we click on skip waiting, it's going to activate our new service worker. And we can see that the cache has now updated so that we just have v3. So we have a couple of different options here. We could check this update on reload, which will always activate the service worker, or we can write the code that will automatically activate the service worker after it is installed. And that seems good to me. So Inside of our install event listener after we add the cache, we are then going to call a method called skipWaiting, and that's it. So now after our service worker is installed, it's going to automatically activate it and we can see that, let's just change the version number, so let's change it to 4. We'll go back, and since browser link automatically refresh the page, we can see that the new service worker was installed, it was activated because we wrote that code, and now we have only v4. So, mow we have two caches, we have a static cache and a dynamic cache. We've also written the code to manage our caches so that we clear out the old cache with every new version of our service worker.

Back to the top