SWR & TTL

[nblopes]

Hi there.

As some of you might know TTL the amount of time a data packet is considered valid in a context. Otherwise it might be simply discarded from the context or revalidated.

I understand that the useSWR hook provides some options to control when revalidation should occur. Yet none cover this case.

Why is this useful?

In context sometimes we don't need always to display the most up to date data to every client at the same time. This feature gives us the opportunity to reduce the number of calls to the server to get new data. In a content driven context this is quite a common scenario.

I have looked at least at one post about this yet it was considered a cache issue. The final suggestion was to somehow use a Custom Cache. Yet this is not a cache issue, it's an internal SWR workflow issue considering that a cache provider has no control over it. It just sets and gets data.

The elegant solution would be to add a config option to useSWR, say { timeToLive: 300000), where provided a specific data packet is in cache (key, data), it would only revalidate, hence fetch a new data packet, after 5 minutes had passed since the last validation of that data packet. This regardless of any other control configurations.

Notice the TTL is specific to each data packet (key, data, ttl)

Of course, calling mutate() manually would bypass the TTL and force a revalidation. This would cover situations where you need to force revalidation.

What do the SWR experts think? I'm just a user.

[nblopes]

Hi, it seams that what I described is the semantics of dedupingInterval option.

I tested it ... and looked like it was.

Am I in the right direction?