Zustand State Management

This skill covers designing and using Zustand stores in React and TypeScript applications, including state ownership decisions, store slicing, selector performance, middleware, SSR, and testing.

State Ownership

• Keep ephemeral UI state in the nearest component with useState or useReducer — don't reach for Zustand by default.
• Use URL state for shareable filters, pagination, tabs, and search params.
• Use Zustand only for client state that is genuinely shared across unrelated components (auth session view state, command palette, cart draft, editor state, etc.).
• Use TanStack Query, SWR, RTK Query, or the project's existing data layer for server state — don't duplicate fetched server data into a Zustand store unless there's a documented offline or draft-editing requirement.
• Implement functional, declarative patterns; avoid classes. Use descriptive variable names with auxiliary verbs like isLoading, hasError.

Store Design

• Model each store as state plus named actions; avoid exposing anonymous setters for component code to misuse.
• Keep stores small and domain-focused rather than one global store for the entire application.
• Split large stores into typed slices, then apply middleware only at the composed store boundary.
• Keep derived values as selectors or small pure helpers unless they must be cached in state.
• Store serializable data by default; keep DOM nodes, promises, sockets, and timers outside store state.