state-management

Use SWR for server state like fetching and caching, Zustand for client state shared across a feature subtree such as filters and selections, and React Context for dependency injection of stable values like auth, environment, and locale.

Create a context holding an inert default store, build the real store once in the provider with useState(() => createStore(...)), and expose narrow selector hooks using useStore. This prevents state leaking between multiple mounted instances of the same component.

Every consumer of a context re-renders when its value changes, so holding rapidly-updating state in context causes widespread re-renders. Use a Zustand store with selector hooks instead so components only re-render when their selected slice changes.

No, server data should live only in the SWR cache and be read through hooks at the point of use. Stores may only narrowly reconcile, such as pruning selected IDs no longer in the server list or seeding an initial value once.

createScopedStore is a generic factory that throws when hooks are used outside its provider, rather than falling back to a dead default store. Today only the date store uses it; the hand-rolled context-plus-createStore shape remains the prevailing idiom for feature stores.