Extending Workbox: Custom strategies and plugins

Key Takeaways

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 could 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 still 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 based 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 inflight 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 inflate 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 inflight 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 walk through 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 routing rules and a properly written strategy will automatically work with all workbox plugins as well this applies to the standard plugins that workbox provides like the one that handles cache expiration but it also applies to plugins that you write yourself because another great way to extend workbox is to write your own plugins so what is a workbox plugin and why would you write your own let's go back to the diagram we looked at before adding 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 the lifetime of a request like when a network request fails or when a cache response is about to be returned to the page each plugin 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 webpage for this information later on as well workbox version 6 has a number of additional lifecycle events that plugins 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 plugin that provides a fallback whenever a strategy would otherwise generate an error 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 okay response he'll use a backup response from the cache instead my colleague andre talks more about using this plugin within a trusted web activity in his chrome dev summit talk and you can watch for that for more details now that you know more about custom strategies and plugins 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 plugin whichever approach to customizing workbox you go with i hope this talk has inspired you to do the following write your own strategies and plugins and then release them on npm tagged with workbox strategy or workbox dash plugin or just share them with the rest of your organization can learn more including a detailed look at all the sample code and events by visiting web.dev slash extending dash workbox thanks to everyone for tuning in now go out there and extend workbox and share what you build