Topic

Challenge: Query or RTK?

Definition

TanStack Query manages server-owned asynchronous data, whereas Redux Toolkit manages shared client-owned state that has no server cache as its source of truth.

In simpler words

Feed posts come from Nest through Query; a half-written post belongs in the RTK draft slice.

The wrong split creates duplicated post arrays and manual synchronization bugs.

Open live example →

After this you can

Classify server versus client state
Invalidate instead of manually mirroring server arrays

Choose one source of truth

Definition

A server-state cache must remain authoritative for remote entities, while client state should represent only local UI information.

In simpler words

Do not keep the same feed collection in both Query and Redux.

Store composer text and local UI preferences in RTK.

Use a mutation then invalidate the feed key after Nest accepts a post.

Keep in mind

Ask “could another user change this on the server?” before choosing RTK.

Challenge lab

Bug report

New posts appear twice after a create succeeds.

What is broken

The submit handler pushes the server result into a Redux feed array and invalidates the Query feed.

Broken snippet

onSuccess(post) {
  dispatch(feedActions.push(post)); // second copy
  queryClient.invalidateQueries({ queryKey: ["feed"] });
}

Pass criteria

One feed source of truth
Draft clears after confirmed success
Feed refreshes after create

Checking your session…

Choose the correct fix

Keep posts in Query, keep only the composer draft in RTK, and invalidate the feed after success.Move Query results and mutations into Redux so every value is in one store.Keep both arrays but skip invalidation after pushing the result.

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. How should the Query/RTK challenge split state?

Concept

RTK for server notes; Query for the draft form stateQuery for both the server notes and the draft formRTK for server notes with Query only for authQuery for server notes/tickets; RTK (or local) for drafts/UI

2. After a successful create mutation?

Syntax

Manually push the new item into component stateReset the entire QueryClient cacheDispatch an RTK action to add it to the storeInvalidate/refetch related queries

3. Draft title while editing?

Practical

PATCH the note on every keystroke via a mutationKeep draft in RTK/local state until saveStore the draft directly in the Query cacheDebounce writes straight to the server with no local state

4. Why not duplicate Query data into RTK by default?

Logic

It makes the store selectors run more slowlyRTK can’t serialize the arrays Query returnsTwo sources of truth driftQuery stops refetching once its data is in RTK

5. Cookies with Axios + Query?

Concept

Read the httpOnly cookie in JS and attach it as a headerEnable withCredentials only on mutations, not queriesShared API client with credentials for NestStore the token in Redux and add an Authorization header

6. Optimistic update caution?

Practical

Rollback on error and keep cache consistentRefetch on success but skip the error pathApply the update without cancelling in-flight queriesUpdate component state instead of the cache

7. Selector for draft slice?

Syntax

Read draft fields from the Query cache with useQueryRead draft fields from RTK store in the formRead drafts from component props passed downRead drafts from localStorage on each render

8. Loading and error UX?

Logic

Track loading with a manual useState booleanWrap every query in a try/catch for errorsUse Query status flags for list/detailRead the loading state from the RTK store instead

9. When is RTK the wrong tool?

Concept

For complex client workflowsAs a replacement for server caching of remote listsFor cross-component draft busesFor undo stacks carefully

10. Challenge done means?

Practical

The list renders once even if it ignores server updatesDrafts save to the server on every keystrokeList reflects server; drafts behave; auth cookies work end-to-endThe UI works while logged out with no auth wired

11. Why invalidate after the create?

Conceptintermediate

useMutation({
  mutationFn: createNote,
  onSuccess: () => qc.invalidateQueries({ queryKey: ['notes'] }),
});

To remove the notes query from the cache permanentlyTo refetch the notes list so it shows the new noteTo optimistically add the note without a refetchTo reset every query in the client at once

12. What rule does this violate?

Syntaxadvanced

const { data } = useQuery({ queryKey: ['notes'], queryFn });
dispatch(notes.setAll(data));

It mutates the Query cache directlyIt duplicates server data into RTK, creating two sources of truthIt skips the queryKey so caching breaksIt should use setOne in a loop instead

13. What belongs in RTK here?

Practicalintermediate

const title = useAppSelector(s => s.noteDraft.title);
const onChange = (e) => dispatch(setTitle(e.target.value));

The fetched list of saved notesThe server’s response to the last saveThe loading and error flags from useQueryThe in-progress draft title before it is saved

14. What must you also handle for a safe optimistic update?

Logicadvanced

onMutate: async (newNote) => {
  await qc.cancelQueries({ queryKey: ['notes'] });
  qc.setQueryData(['notes'], old => [...old, newNote]);
}

Clear the whole cache if the mutation failsRollback on error to keep the cache consistentRefetch on success so no rollback is neededDisable the mutation button until it resolves

15. How should the UI use these flags?

Conceptintermediate

const { data, isLoading, isError } = useQuery(/* ... */);

Render data first and show errors only afterwardUse isLoading but ignore isError for listsShow loading and error states before rendering dataThrow when isError so error.tsx handles it

Checking your session…