Out of the box, TanStack Query is configured with aggressive but sane defaults. Sometimes these defaults can catch new users off guard or make learning/debugging difficult if they are unknown by the user. Keep them in mind as you continue to learn and use TanStack Query:
To change this behavior, you can configure your queries both globally and per-query using the staleTime option. Specifying a longer staleTime means queries will not refetch their data as often
If you see a refetch that you are not expecting, it is likely because you just focused the window and TanStack Query is doing a refetchOnWindowFocus. During development, this will probably be triggered more frequently, especially because focusing between the Browser DevTools and your app will also cause a fetch, so be aware of that.
To change this functionality, you can use options like refetchOnMount, refetchOnWindowFocus, refetchOnReconnect and refetchInterval.
Query results that have no more active instances of useQuery, useInfiniteQuery or query observers are labeled as "inactive" and remain in the cache in case they are used again at a later time.
By default, "inactive" queries are garbage collected after 5 minutes.
To change this, you can alter the default cacheTime for queries to something other than 1000 * 60 * 5 milliseconds.
Queries that fail are silently retried 3 times, with exponential backoff delay before capturing and displaying an error to the UI.
To change this, you can alter the default retry and retryDelay options for queries to something other than 3 and the default exponential backoff function.
Query results by default are structurally shared to detect if data has actually changed and if not, the data reference remains unchanged to better help with value stabilization with regards to useMemo and useCallback. If this concept sounds foreign, then don't worry about it! 99.9% of the time you will not need to disable this and it makes your app more performant at zero cost to you.
Structural sharing only works with JSON-compatible values, any other value types will always be considered as changed. If you are seeing performance issues because of large responses for example, you can disable this feature with the config.structuralSharing flag. If you are dealing with non-JSON compatible values in your query responses and still want to detect if data has changed or not, you can define a data compare function with config.isDataEqual or provide your own custom function as config.structuralSharing to compute a value from the old and new responses, retaining references as required.
Have a look at the following articles from our Community Resources for further explanations of the defaults: