Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Normalize all RequestWrapper lifecycle methods to return a Promise<*> #709

Closed
jeffposnick opened this issue Jul 28, 2017 · 6 comments
Closed
Assignees
Labels
Breaking Change Denotes a "major" semver change.

Comments

@jeffposnick
Copy link
Contributor

Library Affected:
workbox-runtime-caching

The method signature for the public cacheWillMatch() interface is for it to return a Response, but there are use cases in which it would be ideal to perform some asynchronous operation prior to returning that response. In the next major release, we should change the interface to return a Promise<Response> instead.

The concrete use case for this is to perform an IndexedDB lookup prior to returning a response, which would have come in handy when fixing #691

@jeffposnick jeffposnick added Breaking Change Denotes a "major" semver change. enhancement labels Jul 28, 2017
@jeffposnick jeffposnick self-assigned this Jul 28, 2017
@addyosmani
Copy link
Member

In the next major release, we should change the interface to return a Promise instead.

I was about to ask about the use-case, but you have that covered :) Making this change in the next major release SGTM.

@gauntface
Copy link

Should we make this consistent across all plugins, i.e. they all return a Promise?

@jeffposnick
Copy link
Contributor Author

That would probably future proof everything, yes.

@jeffposnick jeffposnick changed the title Change cacheWillMatch() to return Promise<Response> Normalize all RequestWrapper lifecycle methods to return a Promise<*> Aug 2, 2017
@addyosmani
Copy link
Member

Should we make this consistent across all plugins, i.e. they all return a Promise?

👍 Agree with going down this route for consistency sake. Do we need a separate issue for tracking doing this or did you want to reuse the same issue for it?

@gauntface
Copy link

Reuse this one.

@jeffposnick
Copy link
Contributor Author

This was fixed in #736

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Breaking Change Denotes a "major" semver change.
Projects
None yet
Development

No branches or pull requests

3 participants