Zustand vs Redux Toolkit: State Management in 2026
An honest comparison of Zustand and Redux Toolkit for React state management in 2026, covering API design, performance, and team scalability.
Tags
Zustand vs Redux Toolkit: State Management in 2026
Zustand and Redux Toolkit are the two dominant client-side state management libraries for React in 2026. Zustand provides a minimal, hook-based API that lets you create stores in a few lines of code. Redux Toolkit provides a structured, opinionated framework with built-in conventions for slices, async thunks, and entity adapters. The choice between them comes down to team size, application complexity, and how much structure you want your state management to enforce.
TL;DR
Zustand is the better default choice for most React applications. It has a smaller bundle, simpler API, less boilerplate, and excellent TypeScript support. Redux Toolkit is the better choice when you need enforced architectural patterns across a large team, complex state normalization, or extensive middleware for side effects. Both are production-ready and well-maintained.
Why This Matters
State management is the architectural backbone of any non-trivial React application. The library you choose affects how you structure components, handle side effects, manage caching, and onboard new developers. Choosing the wrong tool leads to either unnecessary complexity (Redux for a simple app) or insufficient structure (Zustand for a complex enterprise app).
The React ecosystem has shifted dramatically since Redux's early dominance. React Server Components handle much of what Redux was traditionally used for (server state fetching and caching). TanStack Query and SWR handle async server state. What remains for client state libraries is genuinely client-side state: UI state, form state, local application state, and complex domain logic that lives in the browser.
Understanding what each library does well helps you make the right choice before your codebase is deeply coupled to either one.
How It Works
Zustand: Minimal and Direct
Zustand creates stores as hooks. There is no provider component, no action types, and no reducers. You define your state and actions in a single function.
// stores/cart-store.ts
import { create } from 'zustand';
import { devtools, persist } from 'zustand/middleware';
interface CartItem {
productId: string;
name: string;
price: number;
quantity: number;
}
interface CartState {
items: CartItem[];
isOpen: boolean;
// Actions are part of the same interface
addItem: (item: Omit<CartItem, 'quantity'>) => void;
removeItem: (productId: string) => void;
updateQuantity: (productId: string, quantity: number) => void;
toggleCart: () => void;
clearCart: () => void;
getTotalPrice: () => number;
getTotalItems: () => number;
}
export const useCartStore = create<CartState>()(
devtools(
persist(
(set, get) => ({
items: [],
isOpen: false,
addItem: (item) =>
set((state) => {
const existing = state.items.find(i => i.productId === item.productId);
if (existing) {
return {
items: state.items.map(i =>
i.productId === item.productId
? { ...i, quantity: i.quantity + 1 }
: i
),
};
}
return { items: [...state.items, { ...item, quantity: 1 }] };
}),
removeItem: (productId) =>
set((state) => ({
items: state.items.filter(i => i.productId !== productId),
})),
updateQuantity: (productId, quantity) =>
set((state) => ({
items: quantity <= 0
? state.items.filter(i => i.productId !== productId)
: state.items.map(i =>
i.productId === productId ? { ...i, quantity } : i
),
})),
toggleCart: () => set((state) => ({ isOpen: !state.isOpen })),
clearCart: () => set({ items: [] }),
getTotalPrice: () =>
get().items.reduce((sum, item) => sum + item.price * item.quantity, 0),
getTotalItems: () =>
get().items.reduce((sum, item) => sum + item.quantity, 0),
}),
{ name: 'cart-storage' }
),
{ name: 'CartStore' }
)
);// Using the store in components
function CartIcon() {
// Only subscribes to totalItems - won't re-render when other state changes
const totalItems = useCartStore((state) => state.getTotalItems());
const toggleCart = useCartStore((state) => state.toggleCart);
return (
<button onClick={toggleCart}>
Cart ({totalItems})
</button>
);
}
function CartItemRow({ productId }: { productId: string }) {
const item = useCartStore((state) =>
state.items.find(i => i.productId === productId)
);
const updateQuantity = useCartStore((state) => state.updateQuantity);
const removeItem = useCartStore((state) => state.removeItem);
if (!item) return null;
return (
<div>
<span>{item.name} - ${item.price}</span>
<input
type="number"
value={item.quantity}
onChange={(e) => updateQuantity(productId, parseInt(e.target.value))}
/>
<button onClick={() => removeItem(productId)}>Remove</button>
</div>
);
}Redux Toolkit: Structured and Opinionated
Redux Toolkit organizes state into slices, each with its own reducers, actions, and selectors. The structure is more verbose but provides clear conventions.
// features/cart/cartSlice.ts
import { createSlice, PayloadAction, createSelector } from '@reduxjs/toolkit';
interface CartItem {
productId: string;
name: string;
price: number;
quantity: number;
}
interface CartState {
items: CartItem[];
isOpen: boolean;
}
const initialState: CartState = {
items: [],
isOpen: false,
};
const cartSlice = createSlice({
name: 'cart',
initialState,
reducers: {
addItem: (state, action: PayloadAction<Omit<CartItem, 'quantity'>>) => {
const existing = state.items.find(
(i) => i.productId === action.payload.productId
);
if (existing) {
existing.quantity += 1; // Immer handles immutability
} else {
state.items.push({ ...action.payload, quantity: 1 });
}
},
removeItem: (state, action: PayloadAction<string>) => {
state.items = state.items.filter(
(i) => i.productId !== action.payload
);
},
updateQuantity: (
state,
action: PayloadAction<{ productId: string; quantity: number }>
) => {
const { productId, quantity } = action.payload;
if (quantity <= 0) {
state.items = state.items.filter((i) => i.productId !== productId);
} else {
const item = state.items.find((i) => i.productId === productId);
if (item) item.quantity = quantity;
}
},
toggleCart: (state) => {
state.isOpen = !state.isOpen;
},
clearCart: (state) => {
state.items = [];
},
},
});
export const { addItem, removeItem, updateQuantity, toggleCart, clearCart } =
cartSlice.actions;
// Memoized selectors
export const selectCartItems = (state: RootState) => state.cart.items;
export const selectIsCartOpen = (state: RootState) => state.cart.isOpen;
export const selectTotalPrice = createSelector(selectCartItems, (items) =>
items.reduce((sum, item) => sum + item.price * item.quantity, 0)
);
export const selectTotalItems = createSelector(selectCartItems, (items) =>
items.reduce((sum, item) => sum + item.quantity, 0)
);
export default cartSlice.reducer;// store/index.ts
import { configureStore } from '@reduxjs/toolkit';
import { persistStore, persistReducer } from 'redux-persist';
import storage from 'redux-persist/lib/storage';
import cartReducer from '../features/cart/cartSlice';
const persistConfig = { key: 'cart', storage };
export const store = configureStore({
reducer: {
cart: persistReducer(persistConfig, cartReducer),
},
middleware: (getDefaultMiddleware) =>
getDefaultMiddleware({
serializableCheck: {
ignoredActions: ['persist/PERSIST', 'persist/REHYDRATE'],
},
}),
});
export type RootState = ReturnType<typeof store.getState>;
export type AppDispatch = typeof store.dispatch;// Using Redux in components
function CartIcon() {
const totalItems = useSelector(selectTotalItems);
const dispatch = useDispatch();
return (
<button onClick={() => dispatch(toggleCart())}>
Cart ({totalItems})
</button>
);
}Side-by-Side API Comparison
The same operations expressed in both libraries reveal the difference in verbosity and approach:
// ─── Creating a simple counter ─────────────────────────────
// Zustand: 8 lines
const useCounter = create<CounterState>()((set) => ({
count: 0,
increment: () => set((s) => ({ count: s.count + 1 })),
decrement: () => set((s) => ({ count: s.count - 1 })),
reset: () => set({ count: 0 }),
}));
// Redux Toolkit: 20+ lines
const counterSlice = createSlice({
name: 'counter',
initialState: { count: 0 },
reducers: {
increment: (state) => { state.count += 1; },
decrement: (state) => { state.count -= 1; },
reset: (state) => { state.count = 0; },
},
});
// Plus store configuration, Provider setup, typed hooks...
// ─── Accessing state in components ──────────────────────────
// Zustand: direct selector, no provider needed
const count = useCounter((s) => s.count);
// Redux: requires Provider wrapper and typed hooks
const count = useSelector((state: RootState) => state.counter.count);
// ─── Async operations ───────────────────────────────────────
// Zustand: just use async/await in actions
const useUserStore = create<UserState>()((set) => ({
user: null,
loading: false,
fetchUser: async (id: string) => {
set({ loading: true });
const user = await api.getUser(id);
set({ user, loading: false });
},
}));
// Redux Toolkit: createAsyncThunk
const fetchUser = createAsyncThunk('user/fetch', async (id: string) => {
return await api.getUser(id);
});
const userSlice = createSlice({
name: 'user',
initialState: { user: null, loading: false },
reducers: {},
extraReducers: (builder) => {
builder
.addCase(fetchUser.pending, (state) => { state.loading = true; })
.addCase(fetchUser.fulfilled, (state, action) => {
state.user = action.payload;
state.loading = false;
});
},
});Practical Implementation
TypeScript Support
Both libraries have excellent TypeScript support, but Zustand's is more ergonomic. Zustand infers types from your store definition, while Redux Toolkit requires you to define and export RootState and AppDispatch types, create typed hooks, and use them consistently.
// Zustand: Types flow naturally from the store definition
// No extra type setup needed beyond the interface
// Redux Toolkit: Requires typed hooks boilerplate
import { TypedUseSelectorHook, useDispatch, useSelector } from 'react-redux';
export const useAppDispatch: () => AppDispatch = useDispatch;
export const useAppSelector: TypedUseSelectorHook<RootState> = useSelector;Performance and Re-renders
Zustand provides fine-grained subscriptions by default. Each useStore(selector) call only triggers a re-render when the selected value changes. Redux achieves the same with useSelector, but Zustand's selector-based approach feels more natural because every store access is a selector.
// Zustand: automatic fine-grained subscriptions
const name = useUserStore((s) => s.name); // Only re-renders when name changes
const email = useUserStore((s) => s.email); // Only re-renders when email changes
// For derived data, use shallow comparison
import { shallow } from 'zustand/shallow';
const { name, email } = useUserStore(
(s) => ({ name: s.name, email: s.email }),
shallow
);
// Redux: same pattern with useSelector
const name = useAppSelector((s) => s.user.name);
// For derived data, use createSelector for memoization
const fullName = useAppSelector(selectFullName); // memoized via createSelectorDevTools and Debugging
Redux DevTools is one of Redux's strongest advantages. It provides time-travel debugging, action history, state diff visualization, and the ability to dispatch actions manually. Zustand integrates with the same Redux DevTools extension, but with slightly fewer features.
// Zustand with devtools middleware
const useStore = create<State>()(
devtools(
(set) => ({
// store definition
}),
{
name: 'MyStore',
// Actions appear in Redux DevTools with meaningful names
// when you pass action names to set()
}
)
);
// Named actions for better devtools experience
set({ count: newCount }, false, 'increment');Migration Considerations
If you are migrating from Redux to Zustand, you can do it incrementally. Both can coexist in the same application. Start by creating Zustand stores for new features, then migrate existing Redux slices one at a time.
// Gradual migration: Zustand store that reads from Redux during transition
import { store as reduxStore } from './redux-store';
const useNewFeatureStore = create<NewFeatureState>()((set) => ({
// New state managed by Zustand
newFeature: null,
// Bridge: read from Redux when needed during migration
getLegacyUser: () => reduxStore.getState().user.currentUser,
// Eventually, move user state to Zustand too
}));Common Pitfalls
Using Redux for trivially simple state. If your entire client state is a theme toggle, a sidebar open/close flag, and a user object, Redux Toolkit adds unnecessary abstraction. Zustand or even React context handles this with far less code.
Using Zustand without conventions in large teams. Zustand's flexibility becomes a liability when ten developers each structure their stores differently. If you choose Zustand for a large project, establish and document conventions for store organization, naming, and testing.
Storing server state in either library. Neither Zustand nor Redux Toolkit is designed to be your primary server state cache. Use TanStack Query or SWR for server data fetching and caching. Use your state management library for genuinely client-side state.
Premature optimization with selectors. Both libraries encourage granular selectors for performance, but in practice, most components do not render frequently enough for this to matter. Write simple selectors first and optimize only when you measure actual performance issues.
Not testing store logic independently. Both Zustand and Redux stores can be tested outside of React components. Test your state logic with plain unit tests rather than only through component integration tests.
When to Use (and When Not To)
Choose Zustand when:
- ›Your team is small to medium-sized and values simplicity
- ›You want minimal boilerplate and fast iteration
- ›Bundle size matters (Zustand is roughly 1 KB vs Redux Toolkit's 10+ KB)
- ›You are building a new project and do not need Redux's ecosystem
- ›Your state management needs are moderate in complexity
Choose Redux Toolkit when:
- ›You have a large team that benefits from enforced conventions
- ›Your application has complex state with normalized entities
- ›You need extensive middleware for logging, analytics, or side effects
- ›You want the best possible debugging experience with time-travel
- ›You are maintaining an existing Redux codebase
Consider neither when:
- ›React Server Components and TanStack Query handle all your data needs
- ›Your client state is simple enough for React context and
useReducer - ›You are building a static or content-focused site with minimal interactivity
Both libraries are excellent choices. The React ecosystem is fortunate to have two well-maintained, production-proven options that serve different points on the simplicity-to-structure spectrum.
FAQ
Is Zustand better than Redux Toolkit?
Neither is universally better. Zustand excels in simplicity, minimal boilerplate, and small bundle size, making it ideal for small to medium applications or teams that value developer velocity. Redux Toolkit excels in structured patterns, extensive middleware support, and powerful devtools, making it ideal for large teams and complex applications.
Can Zustand replace Redux in existing projects?
Yes, Zustand can replace Redux incrementally. Both libraries can coexist in the same application, allowing you to create Zustand stores for new features while migrating existing Redux slices one at a time. The conceptual model is similar enough that migration is typically straightforward.
Does Zustand support middleware like Redux?
Zustand supports middleware including persist (localStorage/sessionStorage), devtools (Redux DevTools integration), immer (immutable updates), and custom middleware. The middleware is composed through function wrapping rather than Redux's middleware chain pattern. While the ecosystem is smaller than Redux's, it covers the most common requirements.
What is the bundle size difference between Zustand and Redux Toolkit?
Zustand's core library is approximately 1-2 KB gzipped. Redux Toolkit combined with React-Redux is approximately 10-12 KB gzipped. While both are small compared to most application bundles, Zustand's minimal size makes it particularly attractive when optimizing for initial load performance.
Should new React projects use Zustand or Redux Toolkit?
For new projects with small teams and moderate state complexity, Zustand is the recommended starting point because of its simplicity and low overhead. For new projects with large teams, complex normalized state, or a need for strict architectural conventions, Redux Toolkit provides valuable guardrails that prevent inconsistency across the codebase.
Collaboration
Need help with a project?
Let's Build It
I help startups and established companies design, build, and scale world-class digital products. From deep technical architecture to pixel-perfect UI — let's bring your vision to life.
Related Articles
How to Design API Contracts Between Micro-Frontends and BFFs
Learn how to design stable API contracts between Micro-Frontends and Backend-for-Frontend layers with versioning, ownership boundaries, error handling, and schema governance.
Next.js BFF Architecture
An architectural deep dive into using Next.js as a Backend-for-Frontend, including route handlers, server components, auth boundaries, caching, and service orchestration.
Next.js Cache Components and PPR in Real Apps
A practical guide to using Next.js Cache Components and Partial Prerendering in real applications, with tradeoffs, cache strategy, and freshness considerations.