Beginner TypeScript Guide
Zustand is a lightweight state manager, particularly used with React. Zustand avoids reducers, context, and boilerplate. Paired with TypeScript, you get a strongly typed store-state, actions, and selectors-with autocomplete and compile-time safety.
In this basic guide we’ll cover:
- Creating a typed store (state + actions)
- Using the store in React components with type safety
- Resetting the store safely with types
- Extracting and reusing Store type (for props, tests, and utilities)
- Composing multiple selectors and building derived state (with type inference and without extra re-renders)
- Middlewares with TypeScript support (
combine,devtools,persist) - Async actions with typed API responses
- Working with
createWithEqualityFn(enhancedcreatestore function) - Structuring and coordinating multiple stores
Creating a Store with State & Actions
Here we describe state and actions using an Typescript interface. The <BearState> generic forces the store to match this shape.
This means if you forget a field or use the wrong type, TypeScript will complain. Unlike plain JS, this guarantees type-safe state management.
The create function uses the curried form, which results in a store of type UseBoundStore<StoreApi<BearState>>.
Using the Store in Components
Inside components, you can read state and call actions. Selectors (s) => s.bears subscribe to only what you need.
This reduces re-renders and improves performance. JS can do this too, but with TS your IDE autocompletes state fields.
Resetting the Store
Resetting is useful after logout or “clear session”. We use typeof initialState to avoid repeating property types.
TypeScript updates automatically if initialState changes. This is safer and cleaner compared to JS.
Extracting Types
Zustand provides a built-in helper called ExtractState. This is useful for tests, utility functions, or component props.
It returns the full type of your store’s state and actions without having to manually redefine them. Extracting the Store type:
Using extracted type in tests:
and in utility function:
Selectors
Multiple Selectors
Sometimes you need more than one property. Returning an object from the selector lets you access multiple fields at once.
However, directly destructuring properties from that object can cause unnecessary re-renders.
To avoid this, it’s recommended to wrap the selector with useShallow, which prevents re-renders when the selected values remain shallowly equal.
This is more efficient than subscribing to the whole store. TypeScript ensures you can’t accidentally misspell bears or food.
See the API documentation for more details on useShallow.
Derived State with Selectors
Not all values need to be stored directly - some can be computed from existing state. You can derive values using selectors.
This avoids duplication and keeps the store minimal. TypeScript ensures bears is a number, so math is safe.
Middlewares
combine middleware
This middleware separates initial state and actions, making the code cleaner. TS automatically infers types from the state and actions, no interface needed. This is different from JS, where type safety is missing. It’s a very popular style in TypeScript projects. See the API documentation for more details.
devtools middleware
This middleware connects Zustand to Redux DevTools. You can inspect changes, time-travel, and debug state. It’s extremely useful in development. TS ensures your actions and state remain type-checked even here. See the API documentation for more details.
persist middleware
This middleware keeps your store in localStorage (or another storage). This means your bears survive a page refresh.
Great for apps where persistence matters. In TS, the state type stays consistent, so no runtime surprises.
See the API documentation for more details.
Async Actions
Actions can be async to fetch remote data. Here we fetch bears count and update state.
TS enforces correct API response type (BearData). In JS you might misspell count - TS prevents that.
createWithEqualityFn
Variant of create with equality built-in. Useful if you always want custom equality checks.
Not common, but shows Zustand’s flexibility. TS still keeps full type inference.
See the API documentation for more details.
Multiple Stores
You can create more than one store for different domains. For example, BearStore manages bears and FishStore manages fish.
This keeps state isolated and easier to maintain in larger apps. With TypeScript, each store has its own strict type - you can’t accidentally mix bears and fish.
Conclusion
Zustand together with TypeScript provides a balance: you keep the simplicity of small, minimalistic stores, while gaining the safety of strong typing.
You don’t need boilerplate or complex patterns - state and actions live side by side, fully typed, and ready to use.
Start with a basic store to learn the pattern, then expand gradually: use combine for cleaner inference, persist for storage, and devtools for debugging.