Separate domain state
A large application has unrelated domains such as bears and fish.
Zustand · Const
slices pattern
The slices pattern splits a large Zustand store into focused creator functions and combines them into one bounded store. This keeps state modular while allowing actions to coordinate across slices.
How it works
The slices pattern divides a large Zustand store into focused creator functions. Each creator receives the store arguments such as set and get, returns its state and actions, and the combined store spreads all slice results into one create call. Cross-slice actions can use get to call actions from other slices.
Syntax
create((...args) => ({ ...createSliceA(...args), ...createSliceB(...args) }))Returns
A single Zustand store containing the state and actions returned by all composed slice creators.
Key points
- Split a large store into smaller slice creators to keep related state and actions modular.
- Compose the individual slices into one bounded Zustand store rather than exposing separate store hooks.
- A coordinating slice can trigger actions from multiple slices within one operation.
Common mistakes
- Apply middleware only around the combined store, not separately inside individual slice creators, because the documentation warns that doing so can cause unexpected issues.
Example: Composing Zustand slices
import { create } from 'zustand'
const createFishSlice = (set) => ({
fishes: 0,
addFish: () => set((state) => ({ fishes: state.fishes + 1 })),
})
const createBearSlice = (set) => ({
bears: 0,
addBear: () => set((state) => ({ bears: state.bears + 1 })),
eatFish: () => set((state) => ({ fishes: state.fishes - 1 })),
})
export const useBoundStore = create((...args) => ({
...createBearSlice(...args),
...createFishSlice(...args),
}))
This runnable store composes bear and fish slice creators into one Zustand store; actions from either slice can update the combined state.
When to use it
Cross-slice workflows
Several actions need to coordinate changes across domains.
Modular store organization
A store is becoming difficult to maintain as one object.
Interview questions
QHow does the slices pattern organize a large Zustand store?
The pattern splits a store into smaller creator functions, such as separate bear and fish slices. The final Zustand store combines their returned objects with spread syntax inside one create call.
Follow-up: How can a slice coordinate with another slice? Define a creator that receives get and call another slice's action through get(), then include that creator in the combined store.
QHow are slice creators connected to the Zustand store?
Each slice creator receives the same store arguments and returns its own state fields and actions. Passing the arguments through with a rest/spread form lets every slice use the shared store API.
Follow-up: Why is the combined store bounded? Although implementation is split across files or creators, the spread results become one store exposed by a single hook.
QWhere should middleware be applied when using slices?
Middleware should wrap the combined store rather than individual slices. Applying middleware inside slices can produce unexpected behavior according to the guide.
Follow-up: How would you type middleware-enabled slices? Use the appropriate StateCreator mutator tuple for the middleware, then apply the middleware at the combined-store level.
Related
createsetgetbounded storeStateCreatormiddleware