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

Cache Expiration Behavior + Cache Name + RequestWrapper #122

Closed
gauntface opened this issue Jan 11, 2017 · 4 comments
Closed

Cache Expiration Behavior + Cache Name + RequestWrapper #122

gauntface opened this issue Jan 11, 2017 · 4 comments
Assignees

Comments

@gauntface
Copy link

@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 default cacheName 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:

  1. Cache expiration behavior should get the cache name from the request wrapper, rather than from it's constructor. Pros: Simple and single place for cache name. Cons: Tightly couples it with RequestWrapper
  2. The cache expiration behavior should use the same default as request wrapper. Pros: Simple. Cons: Could be flakey with changes to either class and / or default values.
  3. Request Wrapper shouldn't have a cache name as an option and behaviors should explicitly require cache names where appropriate.
  4. There is a way to get a common default cache from a library and manually pass that in where relevant. Pros: developer control. Cons: Not automatic, could be frustrating sharing same value everywhere.

I'm probably in favor of option 1 or 2.

@jeffposnick
Copy link
Contributor

jeffposnick commented Jan 11, 2017

I think we could get away with not requiring cacheName in the constructor, and relying on the value that gets passed in at runtime via cacheDidUpdate(). There's an assertion making sure that the value that gets passed in at runtime is the same as the value used in the constructor, so it's not like this would be a loss of flexibility.

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.

@gauntface
Copy link
Author

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 👍

@gauntface
Copy link
Author

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.

@jeffposnick
Copy link
Contributor

Reassigned.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants