search

epicweb-dev / cachified

🤑 wrap virtually everything that can store by key to act as cache with ttl/max-age, stale-while-validate, parallel fetch protection and type-safety support
MIT License
916 stars 26 forks source link

Allow me to control the cache time based on the fresh value #25

Closed kentcdodds closed 1 year ago

kentcdodds commented 1 year ago

Related to my use case in https://github.com/Xiphe/cachified/issues/24, if the user has a gravatar, then I'm happy to let that cache hang around for days. If they don't then I want to refresh it every 20 seconds. Maybe the ttl could accept a function which passes the current value if it's available and undefined if not?

Xiphe commented 1 year ago

Sounds like a useful addition! I'm gonna have a look into this within the next days

Xiphe commented 1 year ago

Could you give cachified@3.1.0-context-info.1 a try?

You can now patch the cache metadata during the getFreshValue call.

cachified({
  /* ... */   
  ttl: 5,
  getFreshValue({ metadata }) {
    metadata.ttl = 10;
    return 'value'
  }
});
kentcdodds commented 1 year ago

Thanks for working on this so quickly!

Hmmm... Interesting choice. Is there a reason you didn't go with making ttl a function that accepts the latest value as I suggested?

Xiphe commented 1 year ago

Yeah Multiple reasons.

First and foremost doing it this way was a tiny change

Secondly: The internal pending value cache also uses the ttl. This would have lead to a situation where a ttl-function would be called once with no value to determine the time other calls should wait for the same pending value and a second time once we have the value. Currently this system is transparent to the users and with this change users would need to know about it in order to understand why the ttl-function is called multiple times.

Last but not least this might solve cases like https://github.com/Xiphe/cachified/issues/16 (cc @garand) where by overwriting the createdTime we could dynamically increasing the ttl by the time it took to get a fresh value.

The approach might be a little more imperative then what you proposed but I like that in this case. In my mind it feels like initiating the call with a base set of assumptions and then while getting the fresh value we gain more knowledge and fine-tune some of our assumptions based on that.

kentcdodds commented 1 year ago

Just tried it out and it's great 👍 Thanks!

Xiphe commented 1 year ago

Awesome! It's released now under v3.1.0