Routing Cache Fallback Offline

[00:00:00]
>> Kyle Simpson: Now that we have a cache in place, it's time that we start doing something useful with it. And that involves finally trying to start intercepting the requests that come from the browser through our service worker. Fair warning, from here on out until we actually have a fully working fetch handler.

[00:00:18]
Stuff is gonna be very easy to break on our webpage. Up to this, the service worker has just been sort of sitting there kind of passively doing its thing. But the web page has been working, it's been loading up our files correctly, it hasn't been using the cache.

[00:00:33]
At this point, things get more difficult when you start developing, so before we even jump into that, I just wanna give you the tip that says, be careful about at what point in your project's history, you decide to install an aggressively cashing service worker. Because if you do that on day one of your project, you're gonna have 999 more days on your project that you are juggling service worker frustrations.

[00:01:01]
I typically would recommend that a service worker is kind of later in the process of getting ready to deploy. Certainly it's an important part of it and it may end up impacting the way you need to do routing on your server or whatever, so you don't wannna wait to the very end, but just be aware of that, because as soon as there's a service worker in place, you're gonna for example, gonna have to go in and make sure to bypass the service worker for the network while you're working on regular JavaScript files.

[00:01:28]
Otherwise you'll change your JavaScript file, refresh, even a shift refresh, and it's not gonna end up loading. And it's gonna drive you nuts until you remember I have a caching service worker. I gotta go disable that or delete every time. It just creates more overhead. So be aware of that when you're planning out your project work with service workers.

[00:01:47]
What I did, this may or may not work for you, but what I did was I wrote, when I was building that app I was talking about, I wrote out my service worker, tested it all out, got it to basically do what I wanted it to do, but I had a disable flag at the top of the service worker.

[00:02:06]
And I set it to true and pushed that out. So I knew that my service worker was great, but I had this kill flag that killed everything throughout. I set it to true and then I went on about all the rest of my app development and did shift reloads and all other stuffs.

[00:02:20]
And then when I was ready to deploy, just have to remember to go flip that back fall. So that was not killing my service worker file. So, just think about those various strategies. All right, let's start building out our fetch handler, actually, before we write it here, we need to actually use it.

[00:02:46]
So we'll say self.addEventListener. And the name of it is called fetch.
>> Kyle Simpson: So I'll have onFetch. It's going to receive the request. And remember this request is inbound coming from the page through our service worker. And what we want to do is essentially write a router to handle that.

[00:03:26]
But we need this thing to wait until we have finished all of our work, so I said that it's gonna have the request, it's gonna be the event object. We're gonna need for our event to tell the fetch handler to wait. So remember the event.waituntil and then we're gonna call, we're gonna define another function, which will be an asynchronous function, a router that we pass the request along to.

[00:04:03]
>> Kyle Simpson: And the way we get the request is, it is an object on, or it's a property on the event object.
>> Kyle Simpson: Same thing is happening here that I did with activation, I did an on activate and then an event wait until and divert it to another asynchronous function.

[00:04:34]
Same principles going on here. Okay, let's set up some variables to use in our router. We're going to get the URL. We're gonna use a function that's built under the web platform called URL. It handles basically passing of URL strings for us, so we don't wanna do our own passing of URL strings.

[00:05:06]
>> Kyle Simpson: So by doing dot pathname, what I'm basically saying is, I just want that slash part of the URL, which matches the way you end up doing it, for example, in nodes. So if you worked in node and you getting a request.URL, that's basically the same thing that I'm getting here from that URL parameter.

[00:05:24]
And then I need to get my cache open, so I'm not gonna make the same mistake this time. I'm gonna say caches.open instead of caches.nash, and then I'm gonna use cache name. So at this point we need to decide some things and we're gonna evolve this for a while.

[00:05:45]
We're gonna be coding at this for quite a while. We need to decide how we're gonna handle these inbound requests. And one thing that we might wanna ask is, are we going to handle any requests for outside sources. In other words, if our blog was loading an image from some other CDN, what are we gonna do with that?

[00:06:07]
You might recall at the outset of the workshop, I talked about doing opaque requests for outside resources, and so there's different strategies, there's trade-offs there as to whether or not you want to cash the thing, because if you're relying upon some other resource critically, like you're loading a framework from some CDN for example.

[00:06:27]
If you're loading that from a CDN and. And that's critical for your page to load. And you do an opaque request so you don't need to worry about the course problem. While now all of a sudden is a critical resource of your site that you're not offlining. So you might want to ignore those sorts of requests, it may end up forcing you to think, maybe we should self-host those, instead of sticking those on other locations.

[00:06:57]
So because there's a lot of tricky decisions there, we're just gonna simply skip over that issue. In our workshop example here, our exercise doesn't link to any other resources. But just be aware, that's a whole topic in and of itself. You need to figure out, if I'm dealing with external resources, what's my caching strategy for that?

[00:07:15]
Do I have any strategy whatsoever for the offline ability of that. That may end up including that you try to load it from some other location, but if the page fails to do so, then it has to tell the service worker, I need a backup and now you have some other locally hosted backup of the framework or whatever.

[00:07:35]
So there's a variety of different ways that you may go about that.