Isolate domain state
A large application has independent domains with minimal coordination.
Zustand · Const
multiple stores
Zustand supports multiple stores for separate domains, such as bears and fish. Each store remains isolated and can have its own strict TypeScript type.
How it works
Multiple Zustand stores are separate store instances for distinct domains. Each store owns its state and actions, preserving isolation and giving TypeScript a strict type boundary between domains.
Syntax
const useStore = create<Store>()((set) => ({ ... }))Parameters
| Name | Type | Description |
|---|---|---|
stateCreator | StateCreator<T> | State creator defining one store's initial state and actions. |
Returns
A typed Zustand store hook/API for the specified domain.
Key points
- Use separate stores when domains have independent state and actions.
- A typical split assigns one store to bears and another to fish.
- Domain isolation can make a larger application easier to organize.
- Typing each store separately prevents domain state from being mixed accidentally.
- If state is cohesive but large, modularize it with slices and compose one bounded store.
Common mistakes
- Separate stores are useful for domain isolation, but coordinating state across them requires explicit actions or other integration.
Example: Two domain-specific stores
import { create } from 'zustand'
interface BearState {
bears: number
addBear: () => void
}
interface FishState {
fishes: number
addFish: () => void
}
export const useBearStore = create<BearState>()((set) => ({
bears: 0,
addBear: () => set((state) => ({ bears: state.bears + 1 })),
}))
export const useFishStore = create<FishState>()((set) => ({
fishes: 0,
addFish: () => set((state) => ({ fishes: state.fishes + 1 })),
}))Creates two independently typed stores, each responsible for one domain.
When to use it
Enforce typed boundaries
Different teams or modules own separate state contracts.
Compose slices into one bounded store
A cohesive state model is too large for one state creator.
Interview questions
QWhy might an application use multiple Zustand stores?
The main reason to use multiple stores is to keep unrelated domains isolated. For example, a bear store can manage bears while a fish store manages fish, and each store has its own strict TypeScript type.
Follow-up: When would a single store be preferable? For application-wide global state, the documentation recommends locating it in one store and using slices to divide a large store.
QHow do you define multiple typed stores?
Create each store independently with create, and give each state creator the type for its domain. Components then select state from the relevant store instead of sharing one combined state object.
Follow-up: How can multiple stores be coordinated? Add explicit actions that call the relevant store APIs, or combine related state into one bounded store when atomic coordination is needed.
QWhat benefits do multiple stores provide?
Multiple stores provide separate state containers, so a bear-specific update cannot accidentally be treated as fish state. This makes domain boundaries explicit and can improve maintainability in larger applications.
Follow-up: What is the alternative for a large but cohesive state model? Use the slices pattern to compose smaller state creators into one bounded store.
Related
createslices patternbounded storeStateCreatorpersist