Capítulo 9 de 80
TanStack Query ships with aggressive-but-sane defaults (data is stale immediately, failed queries retry 3x with backoff, inactive cache entries are GC'd after 5 minutes) that catch new users off guard until they're made explicit.
staleTime says otherwise — "stale" doesn't mean "wrong," it means "eligible for a background refetch."staleTime levels: a number of ms (fresh for that long, then refetch-eligible), Infinity (never stale-refetch, but invalidateQueries() still forces one), or 'static' (stricter than Infinity — blocks even manual invalidation and refetchOn*: "always"; use for data that truly cannot change while the app runs, like boot-time feature flags).refetchInterval polling you configure.gcTime): once a query has zero active observers it's "inactive," kept around for gcTime (default 5 minutes) in case it's needed again, then evicted.retry/retryDelay.useMemo/useCallback stability) — JSON-compatible values only; non-JSON values are always treated as changed unless you supply a custom structuralSharing function.| Default | Value | Override |
|---|---|---|
staleTime | 0 (stale immediately) | number of ms, Infinity, or 'static' |
gcTime | 5 minutes | any ms value |
retry | 3 attempts, exponential backoff | retry / retryDelay |
| Structural sharing | on, JSON-compatible values only | structuralSharing: false or custom function |
staleTime: 0 (the default) is why a query seems to "refetch too much" — set it deliberately per query instead of fighting the defaults piecemeal.'static' only for data that cannot change during the app's lifetime; use Infinity for data you still want invalidateQueries() to be able to force-refresh.