Centralized application state
A React application needs shared state without provider or reducer boilerplate.
Zustand · Const
Flux pattern
Zustand recommends a Flux-inspired organization: keep global state in one store, update it through set or setState, and colocate actions with state. Large stores can use slices, while reducer-based Redux patterns remain optional.
How it works
A Flux-inspired Zustand store centralizes application state and updates it through the store's set or setState API. Actions can live beside the state, while slices can modularize a large store; Redux-style reducers and dispatch are optional rather than required.
Syntax
const useStore = create((set) => ({ state: initialValue, action: () => set((state) => ({ state: nextValue })) }))Key points
- Keep application-wide state in one Zustand store.
- Use slices to organize a large store without abandoning the main store.
- Route all store changes through set or setState.
- The update API both merges the requested change and notifies listeners.
- Colocate update functions with the state they modify.
- Choose redux middleware when a reducer-and-dispatch workflow is specifically required.
Common mistakes
- Do not assume Flux or Redux terminology maps exactly to Zustand's behavior.
- Reducers and dispatch are optional; the documented default is to place update functions directly in the store.
Example: A Flux-inspired counter store
import { create } from 'zustand'
type CounterStore = {
count: number
increment: (by: number) => void
}
const useCounterStore = create<CounterStore>((set) => ({
count: 0,
increment: (by) => set((state) => ({ count: state.count + by })),
}))
export function Counter() {
const count = useCounterStore((state) => state.count)
const increment = useCounterStore((state) => state.increment)
return <button onClick={() => increment(1)}>{count}</button>
}The store keeps state and its update operation together; the component selects only the values it uses.
When to use it
Modular large-store design
A growing store contains separate domains such as users, billing, and UI state.
Optional Redux-style updates
A team prefers explicit reducer transitions and dispatch semantics.
Interview questions
QHow does the documented Flux-inspired approach organize global state?
The recommended arrangement is one Zustand store for an application's global state. A large store may be split into slices, but those slices still compose the main store.
Follow-up: How would you retain modularity without creating unrelated global stores? Compose domain-specific slices into the single main store.
QWhy should updates go through set or setState?
Use set or setState for store updates. These APIs merge the described update and notify listeners correctly.
Follow-up: Why avoid mutating state directly? Direct mutation bypasses the store's update and notification mechanism, so subscribed consumers may not be updated correctly.
QAre reducers and dispatch required for a Flux-like design in Zustand?
Zustand lets actions be functions stored directly alongside state, so separate dispatched actions and reducers are not necessary. If Redux-like behavior is needed, a root-level dispatch function or the redux middleware can provide it.
Follow-up: What does the redux middleware add? It connects a reducer and initial state and supplies dispatch on the state and vanilla API.
Related
setsetStateslicesdispatchredux middleware