Choose React State Management

Choose the Right React State Strategy

Classify a value before choosing a library. Give each value one clear owner and one source of truth; do not treat all state as global state.

Preferred Mapping

Local UI state        -> useState / useReducer
Simple shared dependency -> Context
Shared client state   -> Zustand, or Redux Toolkit when architecture warrants it
Server state          -> TanStack Query / RTK Query / framework data APIs
URL state             -> router and search params
Form state            -> native React / form library
Persistent state      -> localStorage or IndexedDB behind an appropriate abstraction

These are defaults, not reasons to replace a project's established, suitable architecture.

Classify Ownership and Lifecycle

Ask who owns the value:

• Backend-owned records, search results, products, users, orders, and remote notifications are server state. They require caching, loading and error handling, invalidation, refetching, deduplication, mutations, and staleness management.
• Interaction state owned by the application, such as an open panel, selected tab, browser-only cart, editor draft, or workflow step, is client state.
• Shareable or navigational values such as filters, search terms, pagination, sorting, tabs, categories, and resource IDs usually belong in the URL.
• Inputs, validation, touched state, field arrays, and submission flow belong to the form.
• Persistence is a storage concern, not evidence that state must be global.

Hybrid boundaries are legitimate. For example, backend data may be copied once into independent editable draft state when a user opens an editor. Make that ownership transition explicit.

Escalate Client State Gradually

Prefer this order:

derive it -> keep it local -> lift it to the nearest common parent
          -> feature Context -> dedicated client store

• Use useState for state owned by one component or a small subtree.
• Lift state to the closest common parent when nearby siblings share it.
• Use useReducer when local transitions become complex, coordinated, previous-state-heavy, or benefit from explicit actions. Multiple object properties alone do not justify a reducer.
• Use Context primarily to distribute simple, infrequently changing dependencies such as theme, locale, authentication session, configuration, dependency instances, or current workspace.
• Avoid a broad Context for frequently updated counters, large editable collections, drag-and-drop, editor, or dashboard state because every Context update makes consumers reconsider rendering.
• Use Zustand for frequently changing client state shared by distant components when Context becomes cumbersome or selectors and domain actions are useful.
• Use Redux Toolkit when a large application or team benefits from strict conventions, middleware, action history, advanced tooling, or complex cross-feature coordination. Prefer RTK Query when Redux Toolkit is already the main architecture.

Respect an existing Redux, Zustand, query, router, or form architecture when it fits the state category. Do not introduce another library without a concrete benefit.

Keep State Minimal and Focused

• Derive values that can be calculated from existing props or state instead of storing them.
• Prefer domain actions such as addItem, removeItem, and clearCart over exposing unrestricted setters from global stores.
• Split client stores by domain rather than creating one store containing unrelated users, carts, editors, notifications, products, modals, and forms.
• Use narrow selectors; do not subscribe a component to an entire Zustand or Redux store when it needs one value.
• Do not globalize form state unless it must genuinely survive navigation or be shared outside the form.

Keep Server State in a Server Cache

Use TanStack Query for remote lifecycle management unless the framework or established architecture provides the appropriate equivalent. Think of it as a server cache, not a client global store.

Do not copy query results into Zustand, Redux client slices, or component state by default. That creates multiple sources of truth and often requires effects to synchronize them. Copy only at an intentional boundary where the value becomes independently owned client state.

Do not manually rebuild loading flags, cache logic, retries, deduplication, background refresh, invalidation, and mutation state in a client store without a specific architectural reason.

Keep URL State in the URL

Read URL-owned values directly through router APIs. Avoid mirroring search parameters into local state with an effect unless there is an explicit, justified synchronization boundary. URL state should remain shareable, bookmarkable, refresh-safe, and compatible with browser navigation.

Handle Forms Separately

Use native React state and framework form APIs for simple forms. Consider React Hook Form, Formik, or the project's established form abstraction for large or nested forms, dynamic arrays, field-level validation, performance constraints, or complex submission flows.

Review Checklist

For each state value, verify:

1. Does it need to be state, or can it be derived?
2. Who owns it: backend, URL, form, persistent storage, or the React application?
3. Can it stay local or be lifted to a nearby parent?
4. Is Context merely distributing a dependency, or being used as a high-frequency global store?
5. Is a client store actually necessary, and are consumers using narrow selectors?
6. Is backend data incorrectly duplicated outside its server-state cache?
7. Are there multiple sources of truth or effects synchronizing state systems?
8. Is one enormous global store mixing unrelated domains?
9. Does persistence work through a clear abstraction without forcing global scope?
10. Does the choice align with the project's existing architecture?

Choose the smallest tool that correctly models the state. The goal is not one state library or the fewest libraries; it is clear ownership and a single source of truth for every category.