 Hi folks, we're going to take a quick tour of some ways of extending Workbox. By the end, you'll be writing your own strategies and plugins and hopefully sharing them with the world. But first, what's Workbox? If you've never heard of it before, you can follow that link to the docs and then come back to this video. At its core, Workbox is a set of libraries to help with common service worker caching scenarios. And when we've talked about Workbox in the past, the emphasis has been on common scenarios. For most developers, the strategies that Workbox already provides will handle your caching needs. Workbox includes ready-to-use strategies like Stale while Revalidate, where a cached response is used to respond to a request immediately, while the cache is also updated so that it's fresh the next time around. Other common strategies, like Network First, falling back to the cache, are available for use as well. But what if you wanted to go beyond these common scenarios? What if your use case involves more arrows? I've got you covered. Let's go beyond the common caching scenarios and talk about customizing Workbox to help with all your caching needs. First, let's cover writing your own custom caching strategies. Workbox version 6 offers a new strategy base class that sits in front of lower-level APIs like Fetch and Cache Storage. You can extend the strategy base class and then implement your own logic in the underscore handle method. Let's go back to that diagram with all the arrows. This represents a strategy that can handle multiple simultaneous requests for the same URL by deduplicating them. A copy of the response is then used to fulfill all the in-flight requests, saving bandwidth that would otherwise be wasted. And here's all the code you need to implement that custom strategy. Just a quick note, this code assumes that all requests for the same URL can be satisfied with the same response, which won't always be the case if cookies or session state information comes into play. I'll link to this code later, but there are a few things I wanted to call attention to. This class extends an existing strategy, network-first, and adds in some additional state mapping the in-flight requests to their corresponding response promises. It overrides the underscore handle method checking to see if there's already an in-flight request for the same URL. If there is, the strategy will wait until there's a response for that earlier request. But if there isn't already an in-flight request for the same URL, our strategy just calls the underscore handle method on its parent class to get a response and adds to the mapping of in-flight requests and cleans up after itself once the response is received. And that's all the code you need. Here's another example of a custom strategy. This is a twist on still while revalidate, where both the network and cache are checked at the same time with a race to see which will return a response first. Let's take a quick walkthrough code that implements that strategy. Like before, our class extends a base. In this case, we're extending a generic strategy class that Workbox provides. This is a good starting point when you need more control over the sequence of network and cache lookups. All of our response generation logic is in the underscore handle method, which has passed two parameters. The browser's request and then a handler parameter, which is an instance of the strategy handler class. Although it's not required, it's strongly recommended that you use the handler parameter to make network requests and interact with the cache like we're doing here. Those handler methods will automatically pick up the cache name you've configured for the strategy, as well as invoke the plug-in lifecycle callbacks that we'll talk about in a bit. A strategy handler instance provides four helper methods. There are fetch and cache put, along with the two others we saw in the previous slide. Writing a Workbox strategy class is a great way to package up response logic in a reusable and shareable form. You can drop any of these strategies directly into your existing Workbox writing rules. And a properly written strategy will automatically work with all Workbox plug-ins as well. This applies to the standard plug-ins that Workbox provides, like the one that handles cache expiration. But it also applies to plug-ins that you write yourself, because another great way to extend Workbox is to write your own plug-ins. So what is a Workbox plug-in and why would you write your own? Let's go back to the diagram we looked at before. Writing in a plug-in doesn't fundamentally change the flow of this diagram, but it allows you to add an extra code that will be run at critical points in a lifetime of a request, like when a network request fails, or when a cache response is about to be returned to the page. Each plug-in responds to one or more lifecycle events, which are invoked when a strategy handler interacts with a network or cache. You can see a list of a few of the existing lifecycle events here. We'll link to a web page for this information later on as well. Workbox version 6 adds a number of additional lifecycle events that plug-ins can react to, all corresponding to different stages in a strategy's lifecycle. Let's combine a couple of those lifecycle callbacks into a reusable plug-in that provides a fallback whenever a strategy would otherwise generate an error-met response. This class implements two lifecycle callbacks, fetch did succeed and handler did error. It can be added to any strategy class, and if running that strategy does not result in a 200 OK response, it'll use a backup response from the cache instead. My colleague Andre talks more about using this plug-in within a trusted web activity in his Chrome Summit talk, and you can watch for that for more details. Now that you know more about custom strategies and plug-ins, you might be wondering which one to write for a given use case. I think a good rule of thumb is to sketch out a diagram of your desired request and response flow. If your diagram has a novel set of connections, like all these extra arrows, then that's a sign that a custom strategy is the best solution. Conversely, if your diagram ends up looking mostly like a standard strategy, but with a few extra pieces of logic injected at key points, then you should probably write a custom plug-in. Whichever approach to customizing Workbox you go with, I hope this talk has inspired you to do the following. Write your own strategies and plug-ins, and then release them on NPM, tagged with Workbox-Strategy or Workbox-Plugin, or just share them with the rest of your organization. You can learn more, including a detailed look at all the sample code and events by visiting web.dev slash extending-workbox. Thanks to everyone for tuning in. Now go out there and extend Workbox and share what you build.