Caching with a Service Worker

[00:00:00]
>> So far, our service worker is useless. It's actually doing nothing. So this console, we're going to remove that. And most of the time that we're going to do here, is to listen for service workers events. I'm going to start with, an event that is called InStyle.I'm going to use Self, as a way to reference the service worker, avoiding the use of 'this', the 'this' object, will have some problem mostly when you are doing OOP, with the class syntax.

[00:00:34]
Anyway, and the service worker will use self And then add event listener. So in this case, we are installing the ServiceWorker. So when the ServiceWorker is being installed, we actually go into something. And something that we typically do here is we ask the caches API, and that's how we access that API.

[00:00:56]
caches we open a cache with a cache name. That's like a folder. If you want, we can call these assets we can create more than one. And this is promise based. So I can use async await, or I can use them. So when the cache is open, Then I can receive that cache object and do something with it.

[00:01:22]
And what we typically doing the first time when we are installing the ServiceWorker is to cache resources one by one with another method or at all Receives an array of assets that I need you to find somewhere. So just here is going to be an array of URLs.

[00:01:46]
For example, I know in my my HTML needs the styles dot CSS object. Yes. So I'm going to start listing my assets So, styles dot CSS app dot JS. And we have SW register dot JS. Okay? So let's see what happens with this. I'm not saying this is done.

[00:02:14]
I'm not saying this is correct but I want to see what happens. So if I run this code, and now if I go back to chrome, we have our first problem. What happens if I refresh? Because I already registered a ServiceWorker. So my ServiceWorker was still there. It's in my computer.

[00:02:37]
I have just changed it in the server, but if I reload which version will use? Well by default, it's always using the version that you have already registered. So let's say it's like the old version, not the new version. When you are, with depth tools, enable in Google Chrome or Microsoft Edge, you can enable this debug tool known as update or reload, update and reload, will actually force a ServiceWorker update, when you reload the patient.

[00:03:14]
That's not going to happen. On normal users visiting your website. Okay? But while debugging, while writing your ServiceWorkers code it's actually a good idea to use that. So I'm going to refresh now. Okay nothing happens be surely which is okay. But now I have something here that says caches storage with a little arrow.

[00:03:39]
And I can open that arrow and I can see a storage within the assets. And if I click there, you can see the three resources that I have shares cached. Okay? And they are there. So now these three assets are in my device. So if I turn off my server, or turn off the WiFi or my connection, we guess that it should be available offline.

[00:04:11]
To actually test that, something that we have is an offline simulator. Also here in the service workers, dev tools. So then we don't need to stop the server. We don't need to turn off our Wi Fi. We just need to click here, refresh and see how our our app will work offline or not.

[00:04:31]
My app is still not working off. Okay.There are many reasons of why it's still not offline ready. But let's say first, that we are not serving the files. We are caching the files, but the service worker is doing nothing automatically. We actually need to write our code. We need to write the server code okay so it's not like an nginx or Apache that has some behavior by default here our server will do nothing okay but also another issue that we have.

[00:05:10]
That's why is this is not completely well done yet, is that we are not serving the HTML. We are not caching the HTML. And if we don't have the HTML, we won't have an app. So you actually need to always cache the HTML. And the most common mistake here is to boot index HTML.

[00:05:30]
Here as a name that we want to cash, it will cash the asset, the HTML, but then it's going to work. Why? Because we are caching URLs, not file names. So don't use index html, use forward slash to represent the root of this domain. Also, we do think about other resources that we need.

[00:05:54]
For example, if we look at our HTML, I think we are good. So we have maybe you're thinking what happened with the icons? Well, because the icon is being installed by the by the browser when we install the app, we don't need to actually cache it. Okay, you can if you want, but there is no need to.

[00:06:11]
And something similar happened with the money First, we don't actually need to hash these files because we are not using those files in our, let's say, web app. These are more like metadata that happens around the PWA and not inside the PWA. But if you go to the CSS We are gonna see that we need one more asset and that Google forms the wealth file.

[00:06:44]
The icons are actually coming from this file so if I don't have that file while offline, I won't have icon. And add that that song sounds good. Which leads to the question. Can we cache assets that are not part of our scope? Because this asset is coming from a different domain.

[00:07:05]
It's a cross domain resource. And the answer is a big Yes. Our service worker can cache assets from the whole web The only thing is that it can only serve that asset to our scope or to its own scope. Okay, so I can cache this file, but it our ServiceWorker can serve that fine only for our PWA and not for other PWA s or websites requesting the file.

[00:07:40]
So I will go to my ServiceWorker, and I will add another acid here, like this. And now I will refresh with update and reload. So now our caches storage has all the assets that we need jog trolley finally rendering the app but for rendering the app we actually need one more step we need the service worker to actually serve the files right now we are just installing the files