Deduplicate requests

Library Affected: workbox-core, workbox-strategies

Browser & Platform: all browsers

Issue or Feature Request Description: Support for deduplicating requests. Or Support for creating custom strategies Or Extend plugin API

Use case 2 API calls to the same endpoint, with the same query, being done at the same time

What I’ve got so far I have cloned the repo (V6) and created a custom strategy. However, the structure is not being very helpful for this case. I cannot base my strategy on another strategy, or even use the strategy as secondary and it depends on a lot of internals.*

Idea I do understand that, apart from the problems, this strategy wouldn’t be as useful as the others currently provided and that creating custom strategies isn’t something that people do every day. So the most elegant solution would probably be to provide a fetch method on the plugin API. The requestWillFetch doesn’t work for this case.

PS: If you like the idea, I can create a pull request. I’ve got a bit familiar with the project and internals.

[jeffposnick]

CC: @philipwalton for his thoughts, as he did most of the Strategy class design.

Passing in a reference to the StrategyHandler (which is what wraps the Fetch API and the Cache Storage API) to the plugin lifecycle methods seems like it could lead to infinite recursion, as the StrategyHandler is what’s responsible for calling the plugin lifecycle methods to begin with. Calling fetch() from within a service worker never triggers the service worker’s fetch event handler to prevent the same thing.

Yep, that would be great! Currently, the only way I was able to create the custom strategy was to clone the entire repository.

I’d imagine that the way this should work while testing is for you to set up a peerDepdendency on workbox-strategies in your package.json, and then do something like:

import {Strategy} from 'workbox-strategies';

class DeduplicateStrategy extends Strategy {
  async _handle(request: Request, handler: StrategyHandler): Promise<Response> {
    // Your code here.
  }
}

And then folks using your custom class (or plugin) would be responsible for installing it and workbox-strategies from npm.

[philipwalton]

It didn’t look like the best approach to me after playing with it, because the _handle method looks like internal API and it’s called “handle”, but receives a “handler” as a parameter. I imagined it’s possible that you can change it at any point, since v6 is in alpha. Speaking of which, do you have any plans to change it?

Yeah, I agree it does make it look like you’re not supposed to define it, but hopefully it’ll be clear with good documentation.

The idea is that the _handle() method actually is private (technically protected) since it should never be called outside of the class defining it.

This is similar to Node’s Readable Streams implementation, where when you create your own streams subclass you have to define the _read() method yourself. I remember this initially struck me as odd the first time I read it, but after thinking about it more it made sense.