-
Notifications
You must be signed in to change notification settings - Fork 826
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
Cache Expiration Behavior + Cache Name + RequestWrapper #122
Comments
I think we could get away with not requiring That sounds similar to what you're describing as option 1, right? Thinking back, the initial motivation for asking developers to pass in the cache name to the constructor might have been so that we could preemptively prune the cache before the first request comes in, but there isn't actually any code written to do that, so it's kind of academic anyway. |
Yeah sounds like option 1. anyway, any fix to this would be great. It's not a blocker for me right now, but I think if you could change this behavior it would be helpful 👍 |
Once your PR lands can you re-assign to me so I can do the minor tidy up in the sw-lib test for cacheName. |
Reassigned. |
@jeffposnick I'm getting a little lost with how these pieces fit together.
A RequestWrapper can take a
cacheName
but if one isn't supplied, a defaultcacheName
is used.The RequestWrapper also takes
behaviors
as an options.The cache expiration behavior requires a
cacheName
.One of the follow needs to be done:
I'm probably in favor of option 1 or 2.
The text was updated successfully, but these errors were encountered: