react-zustand-patternslisted

# Zustand Patterns for React ## Problem Statement Zustand's simplicity hides important timing details. `set()` is synchronous, but React re-renders are batched. `getState()` escapes stale closures. Async actions in stores need careful handling. Understanding these internals prevents subtle bugs. --- ## Pattern: set() is Synchronous, Renders are Batched **Problem:** Assuming state is "ready" for React immediately after `set()`. ```typescript const useStore = create((set, get) => ({ count: 0, increment: () => { set({ count: get().count + 1 }); // State IS updated here (set is sync) console.log(get().count); // ✅ Shows new value // But React hasn't re-rendered yet // Component will see old value until next render cycle }, })); ``` **Key insight:** - `set()` updates the store synchronously - `getState()` immediately reflects the new value - React components re-render asynchronously (batched) **When this matters:** - Chaining multiple state updates - Validating state after update - Debugging "stale" component values --- ## Pattern: getState() Escapes Stale Closures **Problem:** Callbacks and async functions capture state at creation time. Using `get()` or `getState()` always gets current state. ```typescript const useStore = create((set, get) => ({ data: {}, // WRONG - closure captures stale state saveDataBad: (id: string, value: number) => { setTimeout(() => { // If someone passed `data` as a parameter, it would be stale