playbooks

home / skills / busirocket / agents-skills / busirocket-react-state-management-zustand

busirocket-react-state-management-zustand skill

/skills/busirocket-react-state-management-zustand

This skill provides opinionated Zustand patterns for React state management, enabling modular stores, selectors, and modal visibility control.

npx playbooks add skill busirocket/agents-skills --skill busirocket-react-state-management-zustand

Review the files below or copy the command above to add this skill to your agents.

Files (5)
SKILL.md
2.1 KB
---
name: busirocket-react-state-management-zustand
description:
  Zustand state management patterns for React applications. Use when
  implementing global state, modal visibility, cross-component communication, or
  avoiding prop drilling. This is an opinionated pattern recommendation.
disable-model-invocation: true
metadata:
  author: cristiandeluxe
  version: "1.0.0"
---

# React State Management (Zustand)

Opinionated guidance for using Zustand in React applications.

## When to Use

Use this skill when:

- Implementing global UI state (modals, progress indicators)
- Managing shared data across components
- Avoiding prop drilling
- Setting up cross-component communication

## Non-Negotiables (MUST)

- One store per domain (e.g., `uiStore`, `workspaceStore`, `statusLogStore`).
- Keep stores focused; split when they grow too large.
- Use selectors to minimize re-renders:
  `useStore((state) => state.specificValue)`.
- Actions should be defined in the store, not in components.
- Modals should read their visibility state from stores, not receive as props.

## Store Organization

- One store per domain: `uiStore`, `workspaceStore`, `statusLogStore`, etc.
- Keep stores focused; split when they grow too large.
- Use selectors to minimize re-renders:
  `useStore((state) => state.specificValue)`.
- Actions should be defined in the store, not in components.

## Rules

### Zustand Patterns

- `zustand-when-to-use` - When to use Zustand (modals, global UI state, shared
  data)
- `zustand-store-organization` - Store organization (one store per domain,
  selectors, actions)

### Modal Pattern

- `zustand-modal-pattern` - Modal pattern with Zustand (read visibility from
  store)

### Avoiding Prop Drilling

- `zustand-avoiding-prop-drilling` - Use Zustand stores instead of prop drilling

## How to Use

Read individual rule files for detailed explanations and code examples:

```
rules/zustand-store-organization.md
rules/zustand-modal-pattern.md
rules/zustand-avoiding-prop-drilling.md
```

Each rule file contains:

- Brief explanation of why it matters
- Code examples (correct and incorrect patterns)
- Additional context and best practices

Overview

This skill presents an opinionated set of Zustand state management patterns for React applications. It focuses on organizing stores, minimizing re-renders, and practical patterns for global UI state such as modals and cross-component communication. The guidance is concise and intended to be applied directly in TypeScript/React/Next.js projects.

How this skill works

The skill prescribes one store per domain (for example uiStore, workspaceStore) and defines actions inside stores so components remain thin. It emphasizes selectors to subscribe to specific slices of state and avoid unnecessary re-renders. Modal visibility and other UI flags are read from stores rather than passed via props, enabling simpler cross-component communication.

When to use it

  • Implementing global UI state (modals, progress indicators)
  • Sharing data across multiple disparate components
  • Avoiding deep prop drilling and tightly coupled component trees
  • Managing domain-specific state that multiple pages or components consume

Best practices

  • Create one focused store per domain and split stores when they grow too large
  • Define actions inside the store, not inside components, to centralize logic
  • Use selectors (useStore(state => state.value)) to minimize component re-renders
  • Keep modal visibility and UI flags in the uiStore and read them in modal components
  • Favor small, composition-friendly stores over a single monolithic store

Example use cases

  • uiStore for modal visibility, theme, and transient UI flags
  • workspaceStore to hold current project, selections, and permissions shared across pages
  • statusLogStore for global logging, notifications, and progress indicators
  • Replace prop drilling by reading shared state from a zustand store in deeply nested components
  • Define actions like openModal/closeModal in uiStore and call them from toolbar, list items, or routes

FAQ

Why one store per domain instead of a single global store?

Focused stores keep concerns separated, make typing easier, reduce cognitive load, and let you split or lazy-load stores as your app grows.

How do selectors reduce re-renders?

Selectors subscribe components only to the specific state slice they need. When other parts of the store change, components using a selector that didn’t change will not re-render.