State Management in Next.js

State management in Next.js is not a single library decision — it is an architectural decision about where state lives. The App Router makes the boundary between server and client explicit: Server Components can read cookies, databases, and caches during rendering, while Client Components own interactivity, browser events, and global UI state that does not belong in a URL or a database.

The first question is always: does this state need to survive a page refresh? If it lives in the database, it is server state. If it is derived from the URL, it is navigation state. If it is local to a form, dialog, or animation, it is client state. Each category has a preferred tool, and mixing them up is the root cause of most state bugs: over-fetching on the client, hydration mismatches, state leaks between users, and optimistic UI that never reconciles.

This guide covers the patterns that scale in production. We start with server state patterns, move through URL state and React Context, then evaluate Zustand, Redux Toolkit, and TanStack Query. We close with Server Actions, a decision matrix, and the pitfalls that break App Router applications. The goal is to pick the smallest tool that fits each problem rather than one global store for everything.

Server state is data that lives on a server, is fetched asynchronously, and is not owned by the browser. In Next.js, the cheapest place to read it is inside a Server Component, because the fetch happens during rendering, the result can be cached, and no client JavaScript is required to display it. The rule is simple: fetch on the server unless you have a clear reason to fetch on the client.

Server Components can pass data to Client Components through props. This is the most reliable pattern for hydration: the client receives the exact value that was rendered on the server, so there is no mismatch between the initial HTML and the first client render. The Client Component only needs to render the data, not fetch it.

When data must be refreshed after an interaction, Server Actions are the server-side mutation primitive. An action can return a value, update a database, and then invalidate a cache or path. Because the action runs on the server, the returned value is guaranteed to be consistent with the canonical source. The client does not need to guess whether a mutation succeeded.

Caching is an integral part of server state. Next.js caches the result of fetch calls by default, and the React cache() function lets you deduplicate requests across a single render. If you call the same data function twice in a Server Component, wrap it in cache() so only one network request is made. This is especially important when data is read in layouts, pages, and nested components.

The URL is the most underused state container in modern web apps. It is shareable, bookmarkable, survives refreshes, and integrates with the browser back button. In Next.js, useSearchParams and useRouter let you read and write query string state without importing a store library.

URL state is perfect for filters, pagination, modals, and search queries. When a user selects a category, updates the query string, or opens a detail view, the change should often be reflected in the URL. This keeps the UI reproducible and makes analytics straightforward. The server can also read the same search params during a Server Component render, enabling server-side filtering.

The scroll: false option prevents the page from jumping when the query string updates. Use router.replace for filter updates so the back button is not overwhelmed by every minor change, and router.push when the user takes a deliberate navigation action, such as moving to a new page.

React Context is a first-class tool for dependency injection, not a global state manager. It excels at passing values down a subtree without prop drilling: themes, authentication session status, feature flags, and locale preferences. It does not perform well as a high-frequency state store, because every value change re-renders every consumer.

In the App Router, Context requires a Client Component. You cannot create or consume context in a Server Component. The usual pattern is to create a provider in a small client file, import it into a Server Component layout, and place it as low in the tree as possible. The children of the provider remain Server Components if they are not marked with "use client".

Context has well-known limitations. Split unrelated concerns into separate contexts so that changes in one do not cause re-renders in the other. Combine context with useMemo and useCallback to keep the value object stable. Without stability, every render of the provider creates a new context value, which triggers every consumer to re-render.

Zustand is a small, unopinionated state management library that has become the default recommendation for App Router applications. It uses a plain hook-based store, requires no providers, and avoids the boilerplate of Redux. Its footprint is tiny, and it works entirely in client components.

A Zustand store is created with a single function. You define the initial state and actions, and components subscribe to slices of the state with selectors. This subscription model is more efficient than Context because selectors prevent re-renders when unrelated parts of the store change.

Zustand also supports middleware for persistence, immer-based mutations, and devtools. The persist middleware is especially useful for storing UI preferences such as sidebar collapse state, theme mode, or draft form values. Persistence happens in a client component, so it does not affect server rendering.

Redux Toolkit is the right choice when state has complex cross-cutting logic, requires undo/redo, or benefits from a single immutable source of truth with strong TypeScript inference. It is heavier than Zustand, but the Redux DevTools ecosystem and the slice pattern make it maintainable in large teams.

In Next.js, Redux still lives in Client Components. The store must be created once per browser session, wrapped in a provider, and exposed through typed hooks. To avoid hydration issues, create the store in a client provider and initialize it from server-rendered props if necessary. Do not create the store during a Server Component render.

Redux Toolkit also supports RTK Query for server-state caching. While RTK Query is powerful, TanStack Query is more common in Next.js projects. Choose Redux for client state that justifies the boilerplate, and use a dedicated server-state library for server data.

TanStack Query is the leading library for managing server state in React. It handles caching, background refetching, deduplication, mutations, and optimistic updates. It does not replace a global client state store; it owns the asynchronous boundary between the client and the server.

In Next.js, TanStack Query works best in Client Components that need to fetch after hydration, or when the user needs to interactively refetch data. The library also supports prefetching in Server Components and hydrating the query cache so the client does not refetch the same data immediately after hydration.

Prefetching from a Server Component lets you render the initial HTML with the data and dehydrate the query cache into the client. The client provider then rehydrates the cache, so the first render uses the server data without a network request. The query key is the source of truth for invalidation and cache identity.

Mutations use useMutation. After a successful mutation, invalidate the relevant query keys to refresh the UI. The cache is your single source of truth, so mutations do not need to manually update local state unless you are applying optimistic updates.

Server Actions are Next.js's answer to mutations. They run on the server, can be bound directly to forms, and integrate with the cache through revalidatePath and revalidateTag. Because they are functions, not HTTP routes, they reduce the surface area of your API and keep mutation logic next to the components that use it.

When a mutation takes time, wrap it in useTransition. This keeps the UI responsive while the action runs. The transition state lets you show pending UI, and the action result updates the UI once the server responds. For optimistic updates, combine useOptimistic with the transition so the UI responds immediately and then reconciles with the server result.

Optimistic UI is where the client renders the expected result before the server confirms it. React's useOptimistic hook is designed for this pattern. You call it with the current state and an update function, then dispatch an optimistic update while the transition is pending. The hook automatically rolls back to the server state if the action fails.

The right state tool is the one that matches the lifetime and ownership of the data. Server state belongs near the server. Navigation state belongs in the URL. Local UI state belongs in the component, or in a small client store if many components share it. Global state with complex rules belongs in a dedicated store.

Start with the simplest option. If the data comes from the server, fetch it in a Server Component. If the user needs to filter it, put the filter in the URL. If multiple components need to toggle the same UI state, reach for Zustand. Only introduce Redux or TanStack Query when the complexity of the problem justifies the cost of the library and its associated mental model.