Revalidating options of SWR
SWR is a React Hooks for data fetching. It manages cached data and revalidates the cache automatically. This is great, but I see developers who are confused by the SWR’s revalidating behaviors. SWR explains the behavior in the documentation though.
This post explains the behavior. You can see each behavior on the CodeSandbox projects that I’ve created.
## Default behavior
The default option of SWR ( useSWR(key, fetcher) without options) behaves as the following.
- Revalidate when a page has mounted
- Revalidate when a page gets re-focus
- Revalidate when a page gets back to online
- Revalidate when a request has failed
Example: https://codesandbox.io/s/angry-star-ybk38
I’ve often seen confusion why SWR makes so many requests even if the cache data has been stored. This is because of the behavior. But you can customize the behavior by passing options. So let’s see options to handle the revalidating behaviors.
## revalidateOnFocus
default: true
revalidateOnFocus is an option whether SWR revalidates data when a page gets focused or not. This is useful when you want to display the latest data when users get back to a page. But sometimes this leads to unintentional requests. If you want to make requests minimum, you should disable the option.
## revalidateOnReconnect option
default: true
revalidateOnReconnect is a similar option with revalidateOnFocus. But it revalidates data when a page gets back online.
## revalidateIfStale option
default: true
SWR has the revalidateIfStale option and the default value is true. The option indicates whether SWR revalidates data on rendering or not when the cache has stale data. SWR doesn’t revalidate data on rendering when the key has not been changed, so it only affects the behavior on rendering when mounting or the key has been changed. This also doesn’t affect the behaviors of revalidateOnFocus and relivadateOnReconnet.
Example: https://codesandbox.io/s/sparkling-paper-gx9n8
## revalidateOnMount option
default: undefined
revalidateOnMount is an option that only affects the behavior on mounting. If revalidateOnMount is true, its fetcher function is always called on mounting even if data is stored in the cache. If revalidateOnMount is false, its fetcher function is never called on mounting. The default value is undefined, not false, which means the default value doesn’t affect its behavior.
Example: https://codesandbox.io/s/distracted-pasteur-nko4t
⚠️ SWR v1.2.1 doesn’t revalidate data with revalidateOnMount: false even if key has been changed on subsequent updates. I’ve fixed the bug, so it will be fixed in the next release.
## dedupingInterval
default: 2000
depupingInterval is an interval to dedupe requests with the same key. The default value is 2000, which means that revalidations for the same key don’t happen in 2s. This is useful when you want to avoid making many requests for the same URL in a short period.
Example: https://codesandbox.io/s/cool-tdd-fe8ob
## useSWRImmutable
useSWRImmutable is a React Hooks equivalent with the following option. useSWRImmutable doesn’t revalidate data until calling the mutate function explicitly. This is useful for the data that doesn’t change after loading. I feel that the behavior is what some developers assume as the default behavior of SWR.
useSWR(key, fetcher, {
revalidateIfStale: false,
revalidateOnFocus: false,
revalidateOnReconnect: false
})You can use useSWRImmutable by importing from swr/immutable.
Example: https://codesandbox.io/s/wizardly-khorana-iip2r
## Retry on an error
SWR tries to retry a request that is failed by default. You can change the behavior with shouldRetryOnError, errorRetryInterval, and onErrorRetry.
Note: SWR uses Exponential Backoff Algorithm to prevent making too many requests when an error occurred.
## Conclusion
SWR provides us with various ways to handle revalidating behaviors through options, so you can customize the behaviors with its options. If you want to apply a specific option to all useSWR hooks, you can use SWRConfig as a global configuration.
