Topic

TanStack Query fundamentals

Definition

TanStack Query manages asynchronous server state through query keys, query functions, caching, invalidation, and mutation lifecycles.

In simpler words

Give server data a stable cache identity and let Query handle loading, errors, refetching, and stale data.

useQuery, useMutation, query keys, and invalidation.

Open live example →

After this you can

Load and update Nest-backed data without manual cache bookkeeping.
Explain the trade-off to a teammate using a small example.
Name at least one common bug pattern for this topic.

Understand TanStack Query fundamentals

useQuery, useMutation, query keys, and invalidation.

Start by identifying which value or browser behavior changes. Then describe the UI from that current input instead of editing the DOM as a separate source of truth.

TanStack Query fundamentals in code

const ticketsQuery = useQuery({
  queryKey: ["tickets", { status }],
  queryFn: () => ticketsApi.list({ status }),
});

Read the example from data and control flow to the resulting UI. Keep the component boundary small.

Apply TanStack Query fundamentals

Keep rendering as a calculation. Put user-triggered changes in event handlers, preserve UI memory in state, and reserve external synchronization for Effects or the server-state layer.

Name values by their UI meaning, test the loading and error path when data is remote, and avoid keeping two editable copies of the same value.

Ask before adding code: is this local UI memory, shared client state, or Nest-owned server state?

Where bugs hide

Definition

High-bug areas are places where a small API misuse looks correct but produces stale UI, duplicate work, or silent failures.

In simpler words

Each mistake below shows Wrong vs Right code — compare them side by side.

When something misbehaves, match the symptom to a pattern below before rewriting the feature.

Prefer fixing the ownership or update path over adding another Effect or sync step.

Mistake: Unstable queryKey object

// Wrong
useQuery({ queryKey: ["t", { status }], queryFn })
// new filter object identity every parent render without memo

// Right
useQuery({ queryKey: ["t", status], queryFn })

Prefer stable key parts.

Mistake: No invalidate after create

// Wrong
await create(dto);
// list stays stale

// Right
await create(dto);
queryClient.invalidateQueries({ queryKey: ["tickets"] });

Refresh the server cache after writes.

Mistake: Wizard draft in Query

// Wrong
useQuery({ queryKey: ["draft"], queryFn: () => localDraft })

// Right
// RTK / useState for drafts; Query for Nest data

Client-only drafts are not server state.

Live playground

TanStack Query fundamentals sandbox

Change one input at a time and predict the next render.

queryKey filter

Auth cookie
Layouts

Different keys → different cache entries.

Keep in mind

Keep the formal definition in mind; it explains which tool belongs where.
Prefer one source of truth over synchronized copies of the same value.
When behavior surprises you, trace: input → update → render → committed UI.
Study the Wrong vs Right examples in “Where bugs hide” before you merge.

Test

Check your understanding

At least 10 questions — mix of concept, syntax, practical, and logic. Score ≥80% (enforced by the API) to save progress.

Checking your session…

15 questions · concept 5 · syntax 3 · practical 4 · logic 3

1. What is TanStack Query for?

Concept

Managing local form and toggle stateGlobal client state like theme and draftsServer state: caching, fetching, and updating remote dataBundling and routing the application

2. useQuery key purpose?

Syntax

The URL path the query fetches fromA unique React key for list renderingThe staleTime window for the queryIdentify the cached data and its dependencies

3. staleTime meaning?

Practical

How long unused data stays cached before garbage collectionHow long the query waits before its first fetchHow long data is considered fresh before background refetch logic appliesHow long a failed query waits before retrying

4. Where should tickets list live?

Logic

In Query cache keyed by filters — not only local useState as source of truthIn a Redux slice mirrored from the Query cacheIn component useState, refetched in an EffectIn a ref updated after each fetch

5. isLoading vs isFetching?

Concept

Loading often means no data yet; fetching can be background refreshisLoading is background refresh; isFetching means no data yetisLoading tracks mutations; isFetching tracks queriesBoth are true only during the very first fetch

6. Error handling?

Practical

Throw the error so the whole app unmountsSurface error from query and allow retryClear the entire cache on any query errorRetry silently forever without surfacing anything

7. Why not duplicate Query data into Redux by default?

Syntax

Redux renders server data faster than QueryAvoid two sources of truth for server dataQuery data must be normalized in Redux firstSelectors cannot read directly from the Query cache

8. Enabled option use?

Logic

Permanently disable caching for that queryTurn off automatic retries on failurePause background refetching while the tab is hiddenSkip a query until id/auth ready

9. invalidateQueries after mutation?

Concept

Removes the matching queries from the cache entirelyCancels any in-flight requests for those queriesResets the queries to their initialDataMarks related queries stale so UI refreshes

10. Which claim fits this course?

Practical

Query for server state; RTK/local state for client draftsQuery for button hover stateRTK for server lists only alwaysNo caching ever

11. What does including filter in the queryKey do?

Conceptintermediate

const { data, isLoading } = useQuery({
  queryKey: ['tickets', filter],
  queryFn: () => api.list(filter),
});

Caches results per filter and refetches when the filter changesSends the filter to ReduxDisables cachingNames a CSS class

12. What does invalidateQueries do after a create?

Syntaxadvanced

onSuccess: () => queryClient.invalidateQueries({ queryKey: ['tickets'] });

Deletes the tickets tableClears cookiesMarks the tickets queries stale so they refetch fresh dataRemoves the query permanently

13. What does enabled: !!id achieve?

Practicalintermediate

useQuery({
  queryKey: ['user', id],
  queryFn: () => api.user(id),
  enabled: !!id,
});

Disables cachingForces a refetch loopMakes it run twiceSkips the query until id is available

14. What problem does copying this data into Redux create?

Logicadvanced

const { data } = useQuery({ queryKey: ['tickets'], queryFn });
dispatch(setTickets(data)); // also store in Redux

Query can’t render without ReduxTwo caches for the same server data can drift out of syncIt is required for listsRedux is always faster

15. What does staleTime: 60000 mean?

Conceptintermediate

useQuery({ queryKey: ['me'], queryFn, staleTime: 60000 });

The query fails after 60sNest caches SQL for 60sData is considered fresh for 60s before a background refetch is triggeredThe component unmounts in 60s

Checking your session…