Transcript from the "Service Worker Review" Lesson
>> Steve Kinney: We're going to kind of recap some of the stuff from yesterday and talk a little bit more about Service Worker 201. Generally speaking, some of these things fall into that kind of thing we said the other day of, 90% of the time these might not be things that you need until they're definitely a thing that you need, right?
[00:00:24] But it is a certain amount of restraint and thinking about it. They are not the immediate go-to. But there are certain things about Service Workers that you can control that other solutions haven't given us the ability to do in the past, right? And as I mentioned, Service Workers fit in really nicely with this idea of the extensible web manifesto.
[00:00:41] Which is, give me low level access, give me the ability to programmatically decide and change stuff based on the needs of my app. Don't try to assume all web apps must need this and try to come up with some panacea, right? So we have some fine-grained control into the life cycle of Service Workers, where we can either introspect where it is along it's upbringing, coming of age and eventual retirement as a Service Worker.
[00:01:11] As well as being able to push an existing Service Worker out of the way. We can control all those things. It doesn't always mean that we should, it just means that we can, all right? So we do have this fine-grained access that we can look at. And other technologies, we'll talk a little bit about app cache later, didn't give us those.
[00:01:31] And sometimes not having that escape hatch or fine-grained control can lead us to not being able to use the technology the way that we need to for our application.
>> Steve Kinney: So the first one is on the install event, we know that a service worker, when it's been installed, will wait until all of the browser windows or frames have disconnected from it.
[00:01:59] When they've all disconnected, then we know that it is safe for the new service worker to take over. However, there might be a situation where that doesn't work for you. At which point you can call event.skipWaiting, which does exactly what it sounds like. You skip waiting and you push the existing service worker out.
[00:02:18] Now, this can be fraught with peril, because that service worker could have been doing something very important. The client-side code that loaded that service worker might not be the most recent version, right? We are showing you this for the sake of having a comprehensive look at the abilities of service worker.
[00:02:37] Mike and Steve in no way endorse the use of this without a really good reason. And we'll talk about some potentially really good reasons later, but we will make this disclaimer one more time, Mike and Steve do not endorse this without a really good reason. But it exists, and there might be a situation where you might need it.
[00:02:57] The other thing you can do is not only can you push out an existing service worker, but on the activate stage, when a service worker kinda takes the stage and becomes the new, active, service worker, there's the possibility if it is the first service worker, for instance, that there are connected clients that don't have a service worker currently.
[00:03:17] At which point it can tell the browser, anything that doesn't have a service worker, hello, I'm your service worker now, I'll be handling your network request, thank you very much, right? So this will actually take it for all current ones. We saw the life cycle, and in the registration process we have the registration, which is the Service Worker that we literally just registered.
[00:03:40] But we can also look at what the installing Service Worker is. And if you remember the Chrome DevTools, we're able to see that in the DevTools. We're able to see that we have a Service Worker that's installing. We have a Service Worker that was waiting. We have a Service Worker that was active, right?
[00:03:56] In our general programming, we have that same introspection into what's going on in the life cycle of our service worker, right? So there are situations where you might wanna be able to check and see. And we have this fine-grain control over everything happening with Service Worker. And we can see all those things programmatically, which is really cool.
>> Steve Kinney: At the same time, we can also add events, right? In this case, we can add an event listener for an update found, right? Okay, this service worker has taken the stage, but maybe it wants to know about new service workers that come onto the scene, right? There could be a situation where you can make sense to be like, hey, there is a new service worker available, especially for a particularly long-lived application.
[00:04:40] And we could, for instance, listen for this event and present user interface, right? A new service worker's event available, click here to update, right? And then we could theoretically have it take the stage, so on and so forth, right? So we can hear about every new service worker that comes and fire off events for it.
[00:04:58] For the new worker, we can add a state change event, right? When your state changes, I wanna be able to do stuff, right? Again, this is the 201 level, this is not probably your day-to-day relationship with service worker. But the main thing that I want you to get out of this is if there is a very particular need or use case, and Mike's gonna talk about a few of those in a little bit, that you have these tools available.
[00:05:24] You are not at the mercy of service worker, right? You are in control, cool.
>> Steve Kinney: We can also listen for a service worker taking over, right? If the controller changed, if this happens mid-process, we know that somebody probably called skipWaiting. Right, so these are some of the finer-grain ones.
[00:05:46] Again, 99% of the time, you're probably not going to need them, but 1% of the time you're definitely maybe going to need one of them, definitely, maybe.
>> Speaker 2: Can you pass state from new service worker to old service worker or vice-versa?
>> Steve Kinney: The-
>> Speaker 2: [INAUDIBLE] transition.
>> Steve Kinney: That's a good question.
[00:06:03] The existing service worker can intercept the network request. And you could pull it off, you probably shouldn't, right? Could you set stuff in an IndexDB and then have one read it, yeah. I'm gonna say, don't. [LAUGH] Because at that point, you've got changing state in the other one.
[00:06:28] I would say that, could you pull it off, I could come up with ways that you could, and I don't endorse any any of them.
>> Speaker 3: So let me just ask what kind of state were you asking about there?
>> Steve Kinney: Well, I'm envisioning a controller change. And obviously there's the obvious, I'm doing something, I have controller change, stop doing it, don't attempt to complete it.
>> Speaker 3: But I was wondering if the use case for that listener was, I'm in the middle of something, here's what you should do with it new service worker, cuz I've gotten halfway through this process.
>> Speaker 2: Steve's answer, 100% is correct in that case.
>> Steve Kinney: [LAUGH]
>> Speaker 2: I only ask cuz state covers a lot of things.
[00:07:03] There are some situations, for example, we will soon be working with the concept of a fallback image. So instead of getting the usual 404 image, we can store something. Maybe that's something that's not changing very often, that may be something that is sorted in memory over many different versions of the service worker.
[00:07:22] So persisting that, and the kind of thing that Steve's gonna talk about soon, that would be okay. But sort of state that relates to the operation of that service worker, don't do that.
>> Steve Kinney: Okay. Anyway that you could do that would be a colossal hack and you probably shouldn't, right?
[00:07:40] If it's designed not to let you, if you're clever enough, you can find your way around that, but it's definitely a potential sad path.