Add option forceRevalidateOnReconnect to hard-revalidate when regaining a network connection #2776
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.
TLDR
Adds an option
forceRevalidateOnReconnect
, which when set totrue
, triggers a revalidation after reconnecting even whendedupingInterval
hasn't passed yet. To compensate spotty network connections, an optionreconnectThrottleInterval
allows to throttle further revalidations for this event.Background
I'm currently working on an app using SWR with a high
dedupingInterval
(30 seconds). Depending on network availability, the fetcher fetches data either from network or a local cache.Now if users navigate to a screen while offline, and then turn on the network (for example because they see the "no-network" placeholder when there's no cached data), the data won't be revalidated since the 30 seconds of the
dedupingInterval
haven't passed yet.forceRevalidateOnReconnect
With the new option
forceRevalidateOnReconnect
set totrue
(defaulting tofalse
), SWR will callrevalidate()
instead ofsoftRevalidate()
to bypassdedupingInterval
, similar to mutate-events.reconnectThrottleInterval
On spotty network connections, the above new option may trigger a lot of unwanted/unneeded revalidations. For this reason a second option
reconnectThrottleInterval
allows to throttle revalidations on reconnect-events, similar to the existingfocusThrottleInterval
for focus-events.reconnectThrottleInterval
defaults to5000
for consistency withfocusThrottleInterval
.Open questions
Default value for reconnectThrottleInterval
Currently
reconnectThrottleInterval
uses the same default value asfocusThrottleInterval
for consistency.A default value of
0
would preserve backwards-compatible behaviour on reconnect-events, but may not be as good of a default for the feature.Maybe the default value should be even higher, since 5 seconds is quite short in the case of spotty network connections.