feat: staleTime and stale-while-revalidate - #26
Merged
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Until now an entry was either fresh, and served, or expired, and refetched with the caller waiting for it. So the first request after the expiration always paid a full round trip, even if the body was in the cache a millisecond before.
staleTimeadds a freshness window insidelifetime. Past it the cached response is still served right away, and the entry is refreshed in background for the next reader. The subscriber still gets one response, sofirstValueFromkeeps working; a failed refresh keeps the old entry and is not thrown at the caller; parallel hits send a single refresh. It is off by default (staleTime: undefined), nothing changes for who does not set it.The entry now also carries
freshTime, the moment the body came from the backend, soslidingExpirationkeeps an entry into the cache without making it fresh again. Entries stored by an older version fall back toaddedTime. There is a newisStale(entry, req)hook, overridable per request like the others, and nothing is ever stale while rendering on the server.The cache is now read before the queue: while a stale entry is being refreshed its key is in the queue, and joining that request would make the caller wait for the network instead of serving the response we already have.
Eleven tests, each one checked that it fails without the change.