Check out a free preview of the full Progressive Web Applications and Offline course:
The "Cache, Update, and Refresh" Lesson is part of the full, Progressive Web Applications and Offline course featured in this preview video. Here's what you'd learn in this lesson:

After reviewing Cache, Update, and Refresh Caching Strategy, which is when an app updates an asset when it detects a new version on the network, Mike discusses best practices for approaching caching strategies.

Get Unlimited Access Now

Transcript from the "Cache, Update, and Refresh" Lesson

>> Mike North: The last strategy here, and this is probably one of the more complex generic strategies, strategies that have a name, that are accepted as a pattern that we wanna use, it is called the cache and update strategy. So here, the app says I want a resource, the cache goes and gets it for user.

[00:00:23] It goes, makes a fetch to the outside world. And then when it comes back, it's got this thing in the fallback cache. And then the twist on this is remember that from our QR code exercise we have the ability to post message to a worker, and for that worker to post message back to the application.

[00:00:45] So in that case, we can notify the app that a new resource is available, and the application can handle that however is appropriate. So in the case of images, let's say Frontend Masters has a service worker and they change all of the instructor photos. And for some reason, it's really important for those to be live updated.

[00:01:10] You could ask for the instructor photo, and it's gonna go and get. It's gonna say here's the cached one that I've had for the past month. And while you do your thing, I'm gonna go out to the Internet, fetch the new version of it, and I'm gonna let you know when I have it.

[00:01:27] And at that point the app could say, this image is here now. It's been updated. I'm now go and refresh that image and render it on the screen. So some things are safe to like swap out right away. Obviously, not okay for something like JavaScript cuz you have scope to worry about and state.

>> Mike North: So here is a rough idea of the cache and the network strategy. Again, we are having a bias for using the cache first, falling back to the network in the event that the cache is not working out, right, with this fetchFromNetwork in the cache handler, right? And actually, cache the network is what you've already implemented.

[00:02:17] This is the one you're already implemented. So this was the fallback image.
>> Mike North: And here, so we had a specific image that we were using for grocery images, right? We've matched that mime type and had that images path as part of our test to see if this request is for that specific kind of resource.

[00:02:43] This code right here you can copy and paste, like the event.respondWith(. This could be a drop-in for you to have 404 images of whatever you like. So this is one of the things that older offline strategies, like AppCache, did not provide us with a solution for, right? We were stuck with those empty frames of images, and oftentimes, that would result in layout shifting all over the place.

>> Mike North: So with that, we've learned a bunch of caching strategies. We need a means of composing them together. And the two things I want you to remember are the ability to check the URL for certain patterns, comparing origin. Right, so we could do event.request origin, and that would give you, in our case, https://localhost:3000.

[00:03:43] So that's a useful check for certain type of things. Usually for these cash fall back situations, you only wanna deal with your application assets in that case. And the second tool you're gonna use is the acceptHeader. So here's a little cheat sheet for you in an effort to give you a framework for putting something like this in your fetch handler and then diverting out into specific scenario based methods for handling those different cases.

>> Mike North: So in terms of my advice here like precache, I'm just recapping here cuz we're about dive into exercise. Precache assets you know about at build time. Cache on the fly and fall back to assets that come from a database maybe. Our grocery images, those come from a database.

[00:04:40] We don't know all of the URLs for all of the grocery images. So those sort of as you encounter them, store them for later. And then have a bias towards making your app boot really quickly, and it's okay to trade a little bit of freshness in order to get that.

[00:05:02] Because there's real business about you tied to being able to boot quickly. And being one version out of date, oftentimes, if you're building things in a way that is backwards compatible, that shouldn't be a problem. I mean unless there's a security issue or something like that. And we will talk about situations where if you really need to push something out, you can override that.

[00:05:25] You can leave yourself a little escape hatch.