State and Data Libraries in Depth

Lesson 13 gave the overview: what each library is, the staleTime and gcTime clocks, and a first optimistic update. State Management Decisions sorted state into five kinds. This lesson does not repeat those. It goes inside each library: how Redux Toolkit really works, the parts of TanStack Query that interviewers use to separate seniors from juniors (infinite lists, hydration, suspense, races), why Zustand needs no provider and when that bites, and how a form library fits next to them.

All code below was run or type-checked with Redux Toolkit 2.13, TanStack Query 5.104, Zustand 5.0, Jotai 3.0, React Hook Form 7.89 and Zod 4.6 on React 19.

Words used in this lesson

• A store is one object that holds state and lets code read it, change it and subscribe to changes. A subscriber is code that is told when the state changes.
• An action is a plain object that describes what happened, such as { type: 'todos/toggled', payload: 3 }. To dispatch is to send an action to the store.
• A reducer is a pure function (state, action) => newState. It does not change the old state; it returns the next one.
• Immutable means "never changed in place". You make a new copy instead. React and Redux use this to see quickly that something changed (the new object is a different object).
• A selector is a function that reads one piece out of the state, such as s => s.items.length. The component re-renders only if that piece changes.
• Memoization is remembering the last result of a function and returning it again if the inputs are the same.
• Middleware is code that runs between "an action is dispatched" and "the reducer runs". It can log, delay, or start extra work.
• A cache is a stored copy that you reuse to avoid asking again. Hydration is when the browser takes HTML and data made by the server and "wakes it up" so React can take over.
• An atom (Jotai) is one small piece of state, kept outside components, that other atoms can depend on.

Server state and client state: the one rule

Server state is a copy of data that lives on a server and that others can change. Client state is data that only this browser tab owns. Server state needs caching, refetching and error handling. Client state needs a place to live. Mixing them is the most common mistake in this area.

Server state: orders, a profile, a product list. Its natural home is TanStack Query, RTK Query or Server Components. Client state: an open modal, a cart before checkout, a theme. Its home is useState, Zustand, Jotai or a Redux slice. Form fields are neither; a form library owns them. The full sorting is in State Management Decisions.

Redux Toolkit in depth

Redux Toolkit (RTK) is the official way to write Redux. It is a set of helpers that remove the boilerplate of plain Redux. The pieces: configureStore, createSlice, createAsyncThunk, createSelector, createEntityAdapter, the listener middleware, and RTK Query.

Slices and Immer

A slice is the state for one feature plus the reducers and actions that change it. createSlice writes the action types and action creators for you.

Immer is a library inside RTK. It gives your reducer a draft: a special copy-on-write proxy of the state. You write code that looks like a mutation (todo.done = !todo.done). Immer records what you changed and builds a new immutable object, reusing every part you did not touch.

import { createAsyncThunk, createSelector, createSlice, configureStore, type PayloadAction } from '@reduxjs/toolkit'type Todo = { id: number; text: string; done: boolean }export const fetchTodos = createAsyncThunk<Todo[], void, { rejectValue: string }>(  'todos/fetch',  async (_arg, { rejectWithValue, signal }) => {    const res = await fetch('/api/todos', { signal })    if (!res.ok) return rejectWithValue(`HTTP ${res.status}`)    return res.json()  },)const todosSlice = createSlice({  name: 'todos',  initialState: { items: [] as Todo[], status: 'idle' as 'idle' | 'loading' | 'failed', error: null as string | null },  reducers: {    toggled(state, action: PayloadAction<number>) {      const todo = state.items.find((t) => t.id === action.payload)      if (todo) todo.done = !todo.done // looks like a mutation, but state is an Immer draft    },  },  extraReducers: (builder) =>    builder      .addCase(fetchTodos.pending, (s) => { s.status = 'loading' })      .addCase(fetchTodos.fulfilled, (s, a) => { s.status = 'idle'; s.items = a.payload })      .addCase(fetchTodos.rejected, (s, a) => { s.status = 'failed'; s.error = a.payload ?? a.error.message ?? 'Unknown error' }),  selectors: { selectItems: (s) => s.items },})export const { toggled } = todosSlice.actionsexport const store = configureStore({ reducer: { todos: todosSlice.reducer } })export type RootState = ReturnType<typeof store.getState>export type AppDispatch = typeof store.dispatch

What I measured when I ran it:

• After an action that changes something, the state is a new object, and the old one is untouched. After an action that changes nothing (toggling an id that does not exist), the state is the same object. React-Redux relies on this to skip re-renders.
• State is frozen in development. store.getState().todos.items.push(x) throws Cannot add property 1, object is not extensible.
• Inside a reducer you may either mutate the draft or return a new value. Doing both throws: An immer producer returned a new value *and* modified its draft.
• A draft is revoked when the reducer ends. If you keep it in a variable and read it later, you get Cannot perform 'get' on a proxy that has been revoked.

createAsyncThunk

A thunk is a function you dispatch instead of an object. Redux calls it with dispatch and getState, so it can do async work and dispatch real actions later. createAsyncThunk is the standard shape for "call an API". It dispatches three actions: pending, then fulfilled or rejected.

Facts I checked by running it:

Two good habits: pass signal to fetch, so you can cancel with promise.abort(); and use condition to stop duplicate calls. For simple data fetching today, RTK Query (below) replaces most hand-written thunks.

Selectors and reselect

A selector that builds a new array each time is a trap. s.todos.items.filter(...) returns a new array on every call, so React-Redux thinks the value changed and re-renders on every store update. I checked: selector(state) === selector(state) is false.

createSelector (from the reselect library, re-exported by RTK) fixes this. It remembers the last result, and runs your calculation only when an input selector returns a different reference.

export const selectOpenCount = createSelector(  [(s: RootState) => s.todos.items],  (items) => items.filter((t) => !t.done).length,)

In my run, calling it twice with the same state ran the calculation once; after the filter changed it ran again. Notes on reselect 5: the default memoizer keeps results per argument set (it uses WeakMaps), so alternating between two arguments does not recompute; and in development it warns when an input selector returns a new reference for the same arguments (An input selector returned a different result when passed same arguments). Do not wrap a trivial selector (s => s.user.name) in createSelector: there is nothing to save.

createSlice also accepts a selectors field, and the generated selectors take the root state. combineSlices builds the root reducer and wires this up, so counter.selectors.selectValue(store.getState()) works.

Entity adapter, middleware and the listener

• createEntityAdapter stores a list as { ids: [...], entities: { id: item } } (a normalised shape) with ready-made addMany, updateOne and selectors. Finding one item by id is O(1).
• configureStore adds three default middleware in development: thunk, an immutability check, and a serializability check. I dispatched an action holding a Date: it logged A non-serializable value was detected in an action. State should be plain data (numbers, strings, arrays, objects) so devtools, persistence and time travel work. Store ISO strings and convert at the edge.
• The listener middleware (createListenerMiddleware) runs side effects in response to actions: startListening({ actionCreator, effect }). Inside effect you get api.delay, api.cancelActiveListeners and api.condition. It replaces most uses of Redux Saga in new code.

RTK Query

RTK Query is the data-fetching part of RTK. It stores server data inside the Redux store and works with tags to know what to refetch.

import { createApi, fetchBaseQuery } from '@reduxjs/toolkit/query/react'type Post = { id: number; title: string }export const api = createApi({  reducerPath: 'api',  baseQuery: fetchBaseQuery({ baseUrl: '/api' }),  tagTypes: ['Post'],  endpoints: (build) => ({    getPosts: build.query<Post[], void>({      query: () => '/posts',      providesTags: (result) => [        ...(result ?? []).map((p) => ({ type: 'Post' as const, id: p.id })),        { type: 'Post', id: 'LIST' },      ],    }),    addPost: build.mutation<Post, Pick<Post, 'title'>>({      query: (body) => ({ url: '/posts', method: 'POST', body }),      invalidatesTags: [{ type: 'Post', id: 'LIST' }], // refetch the list, not every post    }),  }),})export const { useGetPostsQuery, useAddPostMutation } = api

I ran the same endpoints against a fake base query. Two subscribers to getPosts made one request. After addPost, only the LIST tag was invalidated, so getPosts refetched and a separate getPost(1) did not. Unused data stays for keepUnusedDataFor seconds, 60 by default (TanStack's gcTime is 5 minutes).

Difference in one line: RTK Query invalidates by tags you declare on each endpoint; TanStack Query invalidates by query key you pass at call time.

TanStack Query v5 in depth

Lesson 13 covers the two clocks. These are the parts it skipped.

Keys are a tree, and invalidation walks it

invalidateQueries({ queryKey }) matches by prefix. Design keys from general to specific and keep them in one factory. Add exact: true to match only one entry.

export const todoKeys = {  all: ['todos'] as const,  lists: () => [...todoKeys.all, 'list'] as const,  list: (f: Filters) => [...todoKeys.lists(), f] as const,  detail: (id: number) => [...todoKeys.all, 'detail', id] as const,}// after saving todo 1:qc.invalidateQueries({ queryKey: todoKeys.lists() })                  // all listsqc.invalidateQueries({ queryKey: todoKeys.detail(1), exact: true })   // only detail 1

With four observed queries (two lists, detail 1, detail 2), the two calls above refetched exactly three: both lists and detail 1. Detail 2 was left alone. Also checked: object key order does not matter ({a, b} equals {b, a}), array order does, and a property set to undefined is ignored.

invalidateQueries marks entries stale and refetches only those that are in use on screen (active). Unused ones refetch the next time they mount.

A third value: staleTime: 'static'

Lesson 13 mentioned it. I tested it: with staleTime: Infinity, invalidateQueries() still refetched (2 calls). With 'static' it did not (1 call). Use 'static' for values that cannot change while the app runs.

Mutations and optimistic updates, with the race shown

There are two ways to show a result before the server answers:

1. Via the UI: do not touch the cache. While mutation.isPending, render mutation.variables as a temporary row. If it fails, the row disappears (or stays with a "Retry" button, since variables are kept on error). To show it in another component, use useMutationState with a mutationKey. I ran this: while pending it showed hello; after finishing, it was empty.
2. Via the cache: onMutate writes a guess into the cache, onError restores a snapshot, onSettled refetches.

export function useAddTodo() {  const qc = useQueryClient()  return useMutation({    mutationFn: async (text: string) => { /* POST, throw on !res.ok */ },    onMutate: async (text) => {      await qc.cancelQueries({ queryKey: KEY }) // an older refetch must not overwrite our guess      const previous = qc.getQueryData<Todo[]>(KEY)      qc.setQueryData<Todo[]>(KEY, (old = []) => [...old, { id: -Date.now(), text }])      return { previous }    },    onError: (_err, _text, context) => qc.setQueryData(KEY, context?.previous),    onSettled: () => qc.invalidateQueries({ queryKey: KEY }), // return the promise  })}

I built the race on purpose. A refetch started before the mutation and read the list ['a']. Then I added 'b' optimistically. Without cancelQueries, the old refetch finished after my write, and the cache became ["a"]: the new item vanished, while the server already had ["a","b"]. With cancelQueries, the cache kept ["a","b(optimistic)"]. Rolling back after a failed mutation restored the old list.

Callbacks given to mutate(vars, { onSuccess }) do not run if the component unmounts before the mutation ends. Callbacks given to useMutation still run. Put cache work in useMutation's callbacks, and component-only work (close a modal, navigate) in mutate's.

Infinite queries

An infinite query is a list that grows page by page ("load more" or infinite scroll). The cache holds one entry that contains all pages.

const { data, fetchNextPage, hasNextPage, isFetchingNextPage, status } = useInfiniteQuery({  queryKey: ['projects'],  queryFn: async ({ pageParam, signal }): Promise<Page> => {    const res = await fetch(`/api/projects?cursor=${pageParam}`, { signal })    if (!res.ok) throw new Error(`HTTP ${res.status}`)    return res.json()  },  initialPageParam: 0, // required in v5  getNextPageParam: (lastPage) => lastPage.nextCursor ?? undefined, // undefined or null = no more  maxPages: 5, // keep at most 5 pages in memory and refetch only those})// data.pages is an array of pages: data.pages.flatMap((p) => p.items)

Facts I verified by running it:

• hasNextPage becomes false when getNextPageParam returns undefined or null.
• With maxPages: 3, after loading four pages the cache kept page params [3, 6, 9]; the oldest page was dropped. When refetched, the three kept pages were fetched one after another (3, 6, 9), not in parallel. This stops cursors from going stale. The cost: a refetch of a long list is slow, which is why maxPages exists.
• There is only one fetch at a time per infinite query. Do not call fetchNextPage while isFetching: guard with hasNextPage && !isFetching.
• Use cursor pagination (nextCursor) for lists that change. Offset pagination skips or repeats items when rows are inserted.
• For numbered pages ("page 1, 2, 3") use a normal useQuery with the page in the key and placeholderData: keepPreviousData. I saw the old page shown with isPlaceholderData: true until the new one arrived, so the screen does not flash.

Prefetch and hydration with the Next.js App Router

The goal: the server fetches data, the HTML already contains it, and the browser starts with a full cache and makes zero requests.

// app/get-query-client.tsimport { QueryClient, defaultShouldDehydrateQuery, environmentManager } from '@tanstack/react-query'function makeQueryClient() {  return new QueryClient({    defaultOptions: {      queries: { staleTime: 60_000 }, // above 0, or the browser refetches at once      dehydrate: {        // also send queries that are still loading, so the data streams in later        shouldDehydrateQuery: (q) => defaultShouldDehydrateQuery(q) || q.state.status === 'pending',      },    },  })}let browserClient: QueryClient | undefinedexport function getQueryClient() {  if (environmentManager.isServer()) return makeQueryClient() // new one for every request  return (browserClient ??= makeQueryClient()) // one for the life of the tab}

// app/posts/page.tsx  (a Server Component)export default async function PostsPage() {  const queryClient = getQueryClient()  await queryClient.query(postsQuery).catch(noop) // fetch, cache, swallow the error  return (    <HydrationBoundary state={dehydrate(queryClient)}>      <PostList /> {/* a Client Component that calls useQuery(postsQuery) */}    </HydrationBoundary>  )}

app/providers.tsx is a Client Component ('use client') that renders <QueryClientProvider client={getQueryClient()}>. The Next.js docs say the same: a new client per server render, one client in the browser.

What I ran and saw:

• The server prefetched, dehydrate made a plain object, and renderToString of a component using useQuery produced <p>p1</p>: the data is inside the HTML. A new browser client that received the same state made 0 requests (with staleTime: 60_000).
• The state goes through JSON. A Date became a string. Return plain data from queryFn, or convert it on the way out.
• Failed queries are not dehydrated by default, and pending queries are not either. After I added shouldDehydrateQuery, a query that was still loading was sent too (0 queries before, 1 after). That is how you start a slow fetch without blocking the page.
• getQueryClient() creating a new client on the server avoids sharing one user's cache with another. A cache shared across users is a data leak.

Two more rules from the TanStack docs. First, treat the Server Component as a place to prefetch, not to render the same data. If the server renders posts.length and the client revalidates later, TanStack cannot update the server-rendered text, so the two get out of sync. Second, do not call a Server Action as your queryFn: Server Actions called from the client run one after another, which conflicts with how queries fetch in parallel. Use a Route Handler or a plain API for queryFn. And if you start from a new App Router app, ask whether Server Components alone are enough (Next.js, Lesson 5); the docs themselves suggest starting without TanStack Query until you need it.

Suspense

Suspense is a React feature where a component that is not ready "waits", and the nearest <Suspense fallback> is shown. TanStack provides useSuspenseQuery, useSuspenseInfiniteQuery and useSuspenseQueries.

Differences from useQuery, which I checked:

• data is never undefined at the type level, and there is no isPending. Loading is the fallback; errors go to an error boundary (a component that catches errors thrown below it). Reset the boundary with QueryErrorResetBoundary.
• You cannot use enabled or placeholderData. To avoid the fallback appearing again when the key changes, wrap the key change in startTransition.
• Two useSuspenseQuery calls in one component run one after another (a waterfall: each waits for the one before). Put independent queries in sibling components or use useSuspenseQueries.
• After the first success, a later refetch error does not throw: the component keeps showing the old data. The error is thrown only if there is no data.
• Prefetch on the server and use plain useQuery for that data. If the prefetch is removed by mistake, useQuery simply fetches in the browser, while useSuspenseQuery would suspend.

Zustand in depth

Zustand is a small state library. create returns a hook; the store lives outside React in module memory.

Selectors and the v5 loop

A component that calls useStore(s => s.count) re-renders only when count changes. I counted: with three components, after incA the one reading b did not re-render, but a component that used useStore() with no selector re-rendered on every change.

In Zustand 5 a selector that returns a new object or array each time causes an infinite loop. I got Maximum update depth exceeded with useStore(s => ({ a: s.a })). The fix is useShallow, which compares the object one level deep. With it, an unrelated change caused 0 extra renders.

import { useShallow } from 'zustand/shallow'const { a, b } = useStore(useShallow((s) => ({ a: s.a, b: s.b })))

Better: select each field separately (const a = useStore(s => s.a)). Prefer selecting actions alone too: functions in the store never change, so they never cause renders.

Slices

When the store grows, split it into slices: functions that each return one part of the state and are merged in create. Each slice can still read and write the whole store. This is a code-organisation pattern, not Redux slices.

Persist

persist middleware saves state to localStorage (by default) and loads it back.

export const useStore = create<Store>()(  persist(    (...a) => ({ ...createCartSlice(...a), ...createUiSlice(...a) }),    {      name: 'shop', // key in localStorage      version: 1,      storage: createJSONStorage(() => localStorage),      partialize: (s) => ({ items: s.items }), // do not save UI flags or functions      skipHydration: true, // call useStore.persist.rehydrate() in useEffect    },  ),)

Verified by running: nothing is written at store creation in v5; partialize kept only items in storage ({"state":{"items":[...]},"version":1}); with skipHydration: true the store started with [] and became ['saved'] only after persist.rehydrate(); and a stored version: 1 with a new version: 2 and a migrate function was converted correctly.

Why no provider, and when to add one

React Context needs a provider because the value lives in React. A Zustand store lives in a module variable; the hook subscribes to it with useSyncExternalStore, so any component can import and use it. Benefits: no wrapper, no context re-render problem, and you can read it outside React (useStore.getState()).

The cost is that a module is a singleton (one instance per process). In a browser tab that is fine. On a Next.js server one process serves many users, so a module-level store is shared between their requests. I tested the idea: a "second request" saw the value 42 set by the first. The Zustand docs say: create the store per request and pass it through context, and do not read or write a global store from Server Components.

const createCounterStore = (initial = 0) =>  createStore<CounterState>()((set) => ({ count: initial, inc: () => set((s) => ({ count: s.count + 1 })) }))export function CounterProvider({ initial, children }: { initial?: number; children: ReactNode }) {  const [store] = useState(() => createCounterStore(initial)) // one store per provider  return <Ctx.Provider value={store}>{children}</Ctx.Provider>}

Two providers with initial 1 and 10 showed 1 and 10. Use this pattern also when you need a fresh store per page, per test, or per widget instance.

Jotai and Context, measured

I rendered the same case in each: two components, one reads name, the other reads count, and count changes. How many times did the name component render?

• Jotai (atom) stores state in small pieces. A derived atom (atom(get => get(countAtom) * 2)) updates when its inputs do; I saw 2 after one increment. A write-only atom (atom(null, (get, set) => ...)) holds an action. With no provider Jotai uses a default store; use <Provider> or createStore() for isolated stores.
• Context is the right tool for values that change rarely (theme, locale, a client object) and for passing a store instance down. If you must use it for changing state, split it into several contexts, or keep state and the setter apart.

Difference in one line: Zustand is one store, many selectors; Jotai is many atoms, no selectors; Context is one value, everyone re-renders.

Forms: React Hook Form with Zod

Lesson 13 introduced the setup. Here are the parts that decide real forms.

const Schema = z.object({  email: z.email('Enter a valid email'),  age: z.coerce.number<string>().min(18, 'Must be 18+'),  tags: z.array(z.object({ value: z.string().min(1, 'Required') })).max(3),})type FormIn = z.input<typeof Schema>   // what the inputs hold (age is a string)type FormOut = z.output<typeof Schema> // what handleSubmit gives you (age is a number)const { register, handleSubmit, control, setError, formState: { errors, isSubmitting } } =  useForm<FormIn, unknown, FormOut>({ resolver: zodResolver(Schema), defaultValues: { email: '', age: '', tags: [] } })const { fields, append, remove } = useFieldArray({ control, name: 'tags' })const onValid: SubmitHandler<FormOut> = async (values) => {  const result = await save(values)  if (result.emailTaken) setError('email', { type: 'server', message: 'Already registered' })}

I ran this with a simulated user (jsdom, user-event):

• Typing 3 characters into a field made one extra render of the form, not three (the one was the isDirty flag changing, because I read it). That is the uncontrolled design at work.
• On submit with bad data, both messages showed. Zod issues have paths like tags.0.value, which match nested field names, so errors land on the right input.
• After a valid submit, age arrived as the number 30.
• setError shows an error that came from the server (an email already taken). Always handle this: client validation cannot know about other users.
• useFieldArray gives each row a stable id (f.id). Use it as the React key, not the index, or rows mix up when you remove one.

Gotchas: z.coerce.number() turns '' into 0 (I ran z.coerce.number().parse('') and got 0), so an empty age passes min(0). Check empty strings first. And watch('field') re-renders the whole form on every key press; use useWatch in a small child component instead.

Interview questions

Key takeaways

• Ask "what kind of state?" first. Server data goes in a query cache, not in a client store.
• Redux Toolkit: slices plus Immer (mutate or return, never both), thunks (dispatch never throws, unwrap does), createSelector for computed values, tags in RTK Query.
• TanStack Query: key factories and prefix invalidation, cancelQueries before optimistic writes, initialPageParam and maxPages for infinite lists, new client per server request, staleTime above 0 for SSR, and query() instead of the deprecated prefetchQuery in new 5.x code.
• Suspense: data is never undefined, no enabled, watch the waterfalls.
• Zustand: selectors (and useShallow) decide renders, slices organise, persist needs partialize, version and skipHydration. No provider is a strength in the browser and a risk on the server.
• Context re-renders every reader; atoms and selectors do not.
• Forms: RHF is uncontrolled, Zod gives input and output types, the server has the last word through setError.

What's next

Revisit Lesson 13 for the wider library tour, and State Management Decisions for the sorting rules. For rendering and the re-render rules behind every answer here, read Frontend Depth, Lesson 0 (render and commit) and Frontend Depth, Lesson 1 (hooks and stale closures).