Progressive Web Applications and Offline Progressive Web Applications and Offline

Challenge 10: SPA Treatment of index.html

Check out a free preview of the full Progressive Web Applications and Offline course:
The "Challenge 10: SPA Treatment of index.html" 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:

In this challenge, students incoporate preacaching approaches to an index.html of a SPA.

Get Unlimited Access Now

Transcript from the "Challenge 10: SPA Treatment of index.html" Lesson

[00:00:00]
>> Mike North: Here is the next exercise that we're going to jump into. And this one is a little bit easier than these last two. It's sort of the last piece of the puzzle. And it's interesting because it's handling like one file but sort of not one file. And it has to do with the way Single-page apps work.

[00:00:23] Single-page apps are hack, where we create the illusion of like having addressable content at an app, but behind the scenes we know these are not true page loads. These are not round trip HTTP requests to a server. That we, like in the style that you'd have if you have like a PHP app, where you go and get your PHP to generate some HTML and provide it back to you, right.

[00:00:49] So, our address is changing, our URL is changing. Different stuff is showing up on screen, but really we only have one index.html file, and everything else is sort of an illusion. It's an illusion, so that we align with what users expect from the internet. Right, they expect that they should be able to bookmark something.

[00:01:08] And go back to that book mark and see what they had seen before. So, we have created an illusion, and that has made life a little bit difficult here. Because all of the caching stuff we've been working with so far is oriented towards true addressable resources like a JSON document or an image at a URL.

[00:01:29] Here index.html like in terms of how your browser sees it, that could be coming, that is represented by a variety of URL's. We have to serve up the same html file regardless of what path the user is entering the app through. And in our client side, app will take care of rendering the appropriate content for that thing.

[00:01:54] And I have given you here a variety of hints that will help you build the correct caching logic. For index.html, I like to have this be sort of the outer most caching logic. So we can even, in our fetch event handler, before we even get to the event respond with section that we have now.

[00:02:22] Above that, you could deal with the potential encountering of an HTML request coming in. And in the event that you find one, handle it return and you'll never reach all of the code that we've written so far. Here are two constants that I suggest you put up at the top of your app.

[00:02:41] The only reason that I have the second line here is, occasionally you'll have like the need to serve your app over https or http. This will just match like whatever environment service worker happens to be in, if that is operating over plain http, the index.html URL will have http, otherwise it will have https.

[00:03:05] So, we have a URL there, and that will help us understand what we need to use when we reach into the cache. That is the true URL of that HTML document. In terms of the cache API's point of view, right? It just knows files. Now, down here at the bottom, we've got two checks, the first one lets us use the Accept header to detect whether this is an html request.

[00:03:39] And the second one lets us understand whether this is a local request. So, we're not trying to go for an HTML file for some other domain. Although the service worker can't really do that, but you could have a Chrome extension that has an HTML file. And you might have noticed if you are debugging, you'll see like Chrome://.

[00:04:02] That request will go through your service broker as well which is kind of strange. But this will let you filter out only stuff that's on local host 3000 that is an HTML type. And in the event that you hit those two conditions, we're going to basically do the same thing that we do for dynamic data.

[00:04:23] We have a bias for trying to get a new index.html, in the event that something goes wrong we'll serve up the cached version. Right, so network fall back to cache if something goes wrong. The one that it'll gotcha I want to add to this. We have to cache that index.html page from the start.

[00:04:46] We have to make it's there when we get started. And there's a convenient place to add it. And that is in the caches file where we have our pre caching logic.
>> Speaker 2: They're not shared.
>> Mike North: Thank you. We have our pre caching logic or we're saying pre-cache static assets.

[00:05:08] And we have go and prefetch these files. If we then just to go down here and say oops, go down here and say to pre fetch, push.
>> Mike North: Something like that, now your going to add the root like that index.html request to the things that we go and fetch as the service worker is installed.

[00:05:33] By the time it activates, your going to have an index.html in hand, so that from point on if the user goes offline, when you try fetch to get your fresh index.html you will have something there ready to fall back on too. So, this should be relatively simple and I like the pattern of superseding your existing logic, so just up here, you know, if html request, handle it, return.

[00:06:08] Something like that and then let like you'll skip that chunk of logic in the event that you'd fall into some of the other cases we've been working with. You will know, you have solved this exercise when you can stop your server and your app continues to work. This will get us to fully offline.