comparison/caching

13 notes, read out of this brain and free to use. Each one was extracted from a source and is re-checked against its exam.

React Query lacks normalized caching

React Query, SWR, and RTK-Query do not currently support automatic-normalized caching, which describes storing entities in a flat architecture to avoid high-level data duplication. Apollo Client supports this feature.

React Query caching strategy characteristics

React Query uses Hierarchical Key -> Value caching strategy with JSON cache keys. It performs Deep Compare on Keys with Stable Serialization for cache change detection, Deep Comparison with Structural Sharing for data change detection, and Full Structural Sharing for data memoization.

React Query does not support normalized caching

React Query does not support normalized caching. While most users do not need a normalized cache or benefit from it as much as they believe, some rare circumstances may warrant it. Users should verify their actual requirements before assuming they need normalized caching.

Default gcTime is 5 minutes

The default garbage collection time (gcTime) in TanStack Query is 5 minutes. When no active instances of a query remain, the cached data will be deleted and garbage collected after this timeout period.

Default staleTime is 0

The default staleTime in TanStack Query is 0 milliseconds, which means data is marked as stale immediately after being fetched.

Second query instance with same key uses cached data immediately

When a second useQuery instance mounts with the same query key as an existing query, the cached data is immediately returned from the cache while a new background network request is triggered using the query function.

Garbage collection timeout starts when all instances unmount

When all active instances of a query are unmounted and no longer in use, a garbage collection timeout (gcTime) is set. If no new instances of that query mount before the timeout expires, the cached data is deleted and garbage collected.

Query returns cached data while running background refetch

When a query mounts before the garbage collection timeout has completed, it immediately returns available cached data while simultaneously running the query function in the background. When the background fetch completes successfully, the cache is updated with fresh data.

Caching lifecycle story example

The caching lifecycle demonstrates: (1) A new query with a fresh key shows hard loading and fetches data; (2) A second instance with the same key uses cached data and refetches in background; (3) When all instances unmount, a gcTime timeout starts; (4) A new instance mounting before timeout returns cached data and refetches; (5) After all instances unmount and gcTime expires, the cache is deleted.

staleTime option values and behavior

A Query with a staleTime set is considered fresh until that staleTime has elapsed. Set staleTime to a duration in milliseconds (e.g., 2 * 60 * 1000 for 2 minutes) to read from cache without refetching. Set staleTime to Infinity to never trigger a refetch until manually invalidated. Set staleTime to 'static' to never trigger a refetch, even if manually invalidated.

staleTime 'static' vs Infinity difference

'static' and Infinity both prevent staleness-based refetches, but 'static' is stricter. queryClient.invalidateQueries() can invalidate a query with staleTime: Infinity, but has no effect on staleTime: 'static'. Also, refetchOnMount, refetchOnWindowFocus, and refetchOnReconnect set to 'always' are blocked by 'static'. Use 'static' for data that cannot change while the app is running (e.g., feature flags, user permissions, static reference tables). Use Infinity when manual invalidation should still work.

Default garbage collection time for inactive queries

Query results with no active instances of useQuery, useInfiniteQuery, or query observers are labeled as 'inactive' and remain in the cache. By default, inactive queries are garbage collected after 5 minutes (1000 * 60 * 5 milliseconds). This can be changed by altering the default gcTime option.

Structural sharing behavior

Query results by default are structurally shared to detect if data has actually changed. If data has not changed, the data reference remains unchanged to help with value stabilization with regards to useMemo and useCallback. Structural sharing only works with JSON-compatible values; other value types are always considered as changed. This can be disabled with config.structuralSharing flag, or a custom function can be provided to compute a value from old and new responses.

Give your agent this brain