Feature request: Add maxAge option for cached values

[nulladdict]

We currently have dedupingInterval option, which acts as a soft TTL for cached values, meaning that after this timeout hits we still use cached value but need to revalidate it.

I propose adding maxAge option, which would act as a hard TTL, meaning that when this timeout we can no longer use cached value, and have to hard revalidate it (return undefined / suspense depending on options).

This effectively allows to create a boundary, where stale value is okay to use, and the timeline would look something like this:

I believe after #231 gets merge this could be possible to do outside of the library by clearing the cache when maxAge hits, but I believe this feature is good enough to be built-in

[baer]

👋hi @nulladdict. Your description is very clear and I love the diagram! I also would really love to see this feature. Applications I work on have long-lives (as in weeks) sessions so SWR, as it's written, could show dangerously stale data.

This issue has been discussed in a bunch of places throughout the repo. It may be better to close/delete this issue and link/repost on of those discussions.

#4 - On how to evict old cache items. On that issue, the author talks a bit about their plans for exposing their internal cache interface.

#16 - Where folks are discussing how to use other storage mechanisms (in addition to or replacing) the JavaScript Map function.

#231 - Where a PR that exposes the cache was merged without documentation or examples. I suspect that's coming soon.

[majelbstoat]

I would vote to keep this issue open as it's the only one that specifically describes maxAge. The storage mechanism is orthogonal to this problem, and exposure of the cache (which is now released) still requires some kind of complex setInterval dance in a component high up the component tree. I agree this is a good enough feature to be built-in.

A specific example where this is important is an editor, where changes are being saved to a server. When leaving the editor then hitting "back", SWR will show the previously loaded text for a moment, until the latest draft loads. This can cause issues on slow connections where further edits to the text cause conflicts because the base of edits is incorrect.

A workaround is to use mutate() to invalidate the key. But, with an editor, you'd want to do that on every keystroke, which is pretty undesirable and inefficient. It would be far easier to call SWR in such a way as to guarantee freshness, and a maxAge of 0 would handle that nicely.

[nulladdict]

I don't think your example quite fits the SWR's paradigm. By using this strategy you get eventual consistency, which means it's okay for values to be stale for some time, since eventually they will be consistent.

The option I described is more for the long-lived resources. They are somewhat fresh as long as user interacts with them, but if user leaves them be for a long period of time they might become too stale to be shown. Basically maxAge allows "coming back after a long time" interaction feel more like "first time" interaction.

Also maxAge of 0 probably wouldn't work well, since it might lead to infinite loop of reading and revalidating of resource, especially in suspense mode.

[baer]

@nulladdict it's been ~1y and SWR has come a long long way. For whatever part you played in that, thank you! There are now several ways to handle the above using SWR's options either globally or on a per-key basis. Specifically:

• refreshInterval can be used as a pseudo maxAge
• revalidateOnFocus/revalidateOnReconnect could be used to handle applications with long-lived sessions but somewhat infrequent use
• mutate("key") can globally invalidate any cache key manually whether that's on an interval or triggered by an event

IMO, this issue can be closed!

[shuding]

Worth mentioning: we’re also landing this custom cache feature #1017 in 1.0, in which you can control the cache behavior by yourself if you have an advanced use case.

[daveycodez]

Idk why this was closed that never addressed maxAge