English for Zustand State Management

Zustand’s minimal API means most of the terminology it needs comes from how teams organize state around it — stores, selectors, slices — rather than from the library’s own surface, so being precise about those organizational terms is what actually makes a Zustand discussion clear.

Key Vocabulary

Store — a hook created by create() that bundles state and the actions that update it into a single callable unit, the fundamental building block of a Zustand app. “We have a separate useCartStore and useAuthStore rather than one giant store — it keeps each store’s responsibility narrow and easy to test.”

Selector — a function passed to a store hook that extracts a specific slice of state, used to avoid re-rendering a component when unrelated state in the same store changes. “The component was re-rendering on every store update because it wasn’t using a selector — subscribing to state => state.cartTotal instead of the whole store fixed it.”

Action (co-located action) — a function defined inside the store itself that updates state via set, kept alongside the state it modifies rather than dispatched from outside like a Redux action. “Zustand doesn’t have a separate action-dispatch layer — the addToCart action lives right in the store definition and calls set directly.”

Slice pattern — the convention of splitting a large store’s definition into separate functions (one per domain concern) that are combined into a single store, keeping the store’s file manageable without creating multiple stores. “Instead of one 400-line store file, we split it into a slice for cart state and a slice for filters, and composed them together in the final create() call.”

Middleware (persist, devtools, immer) — a wrapper function applied around the store creator that adds cross-cutting behavior like localStorage persistence, Redux DevTools integration, or Immer-based immutable updates. “We wrapped the store in persist middleware so the cart survives a page refresh, and in devtools so we can inspect state changes during debugging.”

Common Phrases

• “Are we subscribing with a selector, or pulling the whole store and causing unnecessary re-renders?”
• “Is this action defined inside the store, or is state being mutated from outside it?”
• “Should this be its own store, or a slice within the existing one?”
• “Is persist middleware applied here, or will this state reset on refresh?”
• “Is this update going through set, or mutating state directly?”

Example Sentences

Reviewing a performance issue: “This component re-renders on every store change because it’s not using a selector — subscribe to just state.isOpen instead of destructuring the whole store.”

Explaining a store design decision: “We kept auth and cart as separate stores rather than slices of one store, since they have completely different lifecycles — auth persists across sessions, cart doesn’t need to.”

Describing middleware usage in a PR: “Wrapped the settings store in persist so preferences survive a refresh, and left devtools on for local development only.”

Professional Tips

• Say selector explicitly when discussing a re-render bug — “it’s re-rendering too much” without naming whether a selector is missing leaves the actual fix ambiguous.
• Decide between a new store and a slice deliberately and explain the reasoning — splitting state that’s tightly coupled across multiple stores tends to create synchronization bugs.
• Name the specific middleware in play when debugging persistence or devtools issues — “state isn’t saving” is much less actionable than “persist middleware isn’t wrapping this store.”
• Keep actions co-located with the state they modify and point this out in review — an action defined outside the store that calls set from a distance is harder to trace later.

Practice Exercise

1. Write a sentence explaining why a selector prevents unnecessary re-renders.
2. Describe when you’d split a store into slices versus creating a separate store.
3. Explain what persist middleware does in one sentence.