web-state-zustand_skill

Overview

This skill explains client state management patterns with a strong recommendation to use Zustand for shared UI state and useState for local component state. It clarifies when to use URL params, when to avoid Context for state, and enforces conventions like named exports and constant usage. Follow the decision tree to pick the correct tool and avoid common anti-patterns.

How this skill works

The skill inspects a state use case and guides you through a decision tree: is the data server-originated, URL-shareable, needed in multiple components, truly local, or a singleton dependency? It recommends a data fetching solution for server data, URL params for shareable filters, Zustand for shared UI, and useState for local state. It also flags common pitfalls, performance risks, and version-specific gotchas for Zustand.

When to use it

• Deciding between useState and Zustand for a specific piece of state
• Setting up shared UI state used by 2+ components (modals, sidebar, cart)
• Ensuring server data stays in a data-fetching layer, not client state
• Designing shareable filters or pagination using URL params
• Establishing form state/validation patterns with controlled inputs and Zod

Best practices

• Always use a data fetching solution for any server/API data; never store server data in client state.
• Use Zustand for state shared by 2+ components; use useState only for truly local state.
• Never use Context for state management—Context is only for dependency injection or singletons.
• Use named exports in all state files and declare numeric values as named constants (no magic numbers).
• Prefer URL params for bookmarkable/shareable UI state (filters, search, pagination).

Example use cases

• Global modal control: header triggers open, layout renders modal — implement with a Zustand store.
• Sidebar collapsed state shared between header toggle and sidebar component — manage in Zustand.
• Form inside a dialog: keep inputs controlled locally with useState or React Hook Form + Zod, lift only shared flags to Zustand if needed.
• Search page filters that must be shareable/bookmarkable — store in URL searchParams and sync with Zustand if necessary.
• Avoid storing API-fetched product list in Zustand; use your data fetching layer with caching instead.