Exploring Service Workers Specifying Cached URLs
Transcript from the "Specifying Cached URLs" Lesson
>> Kyle Simpson: So let's make our service worker do something a little bit more interesting than just send messages around. Let's make it actually start proactively caching things, since this is going to be another major change to our service worker and I'm going to update it to version # 3.
[00:00:14] And I'm going to choose as because I'm tracking those versions. I'm going to choose to keep all of my cache files in a version cache name. And that sounds more sophisticated than it is. It just means that I have a string called cacheName, which has the version number included in it.
[00:00:32] So I'll just give it some useful name like ramblings and then include my version number in there. So that's just gonna say ramblings-3 or ramblings-4. That's just a string name to refer to my collection of my cached items. What that means is that anytime I update my version, all of the files are gonna get re-cached under a new cache name and the old caches are gonna go away.
[00:00:59] If you don't want to do atomic updates, then you would use a cache name that was fixed rather than version dependent. And then you just have to manage determining whether or not something had been updated. You might for example have an API on your server like a backend admin API.
[00:01:16] That the service worker can hit and it gives it a list of only the resources that have updated and then you incrementally put those in the cache. There's lots of ways that you might approach it, I'm just going to go the sort of all or nothing update approach here.
[00:01:31] Okay, so we now have a cacheName, but we need to know what we want to cache. There's a couple of different ways that we might go about this, but I'm going to choose kind of the easiest for these purposes. I'm going to hard code into my service worker, the logged out resources that I want, and by logged out I mean the stuff that's not sensitive to the sessions.
[00:01:53] I'm going to cache those resources by listing them specifically in an array. Again, this could be something that you load from your server dynamically if you prefer to go that route. A lot of people have their service worker generated by their build process and it just dumps all of their resources into the service worker.
[00:02:12] Kind of like a template, it just dumps them in. So, however you would like to go about that, we're gonna make urlsTocache, as an object. And I'm gonna make a distinction, although for our purposes, it won't matter. I'm gonna make a distinction of resources that I'm calling, let me not say is logged out.
[00:02:36] I'll just call them loggedOut.
>> Kyle Simpson: I'll call them loggedOut, so that theoretically we can have another list of resources that are sensitive to a session, and we only cash those when somebody is actually logged in. I've used that in my app, for example, that I cached the admin pages, but only for an admin user.
[00:03:06] And so I have that list that gets populated with resources, but only for admin users. I don't want to push all of the admin code out there unnecessarily for people that aren't admins. So you can distinguish between the two, for our purposes in this workshop, basically,we're we only need this one list.
[00:03:23] Okay, so I'm going to grab, I'm going to start listing strings for all these things. And if you were to open up the web directory, it's basically all of these web files that we need to be able to load. So I'm going to start listing each one of these.
>> Kyle Simpson: You might choose to order these in a particular way.
[00:04:18] If there was something like more critical than something else, you might put the more critical ones at the top, for our purposes it doesn't matter.
>> Kyle Simpson: I'll start listing out the pages that I know we wanna cache, like /, /about, /contact, /login. That's just the login form page, that's not anything else and then /
>> Kyle Simpson: Okay, there's our list of URLs that we want to make sure we've cached.