Redux Toolkit is the official, batteries-included way to write Redux logic, and it cuts boilerplate by roughly 70% while enforcing best practices. If you're a full-stack developer managing shared client state, this guide shows you how to set it up, avoid common pitfalls, and scale it in production.
I've spent years building React apps with both vanilla Redux and Redux Toolkit, and the difference is night and day. Vanilla Redux requires you to hand-write actions, action creators, reducers, and immutable update logic — a process that's verbose and error-prone. Redux Toolkit simplifies this with a single createSlice API, built-in Immer for mutable-style updates, and a pre-configured store. But it's not a silver bullet; knowing when to use it is half the battle.
Why Redux Toolkit Matters (and When to Skip It)
Redux Toolkit matters because it eliminates the three biggest pain points of classic Redux: manual action creators, immutable spread logic, and complex store configuration. With createSlice, you define a state shape, reducers, and actions in one block of code. The included createAsyncThunk handles loading states for API calls without you writing isLoading flags by hand.
However, you should skip it for apps with purely local or server-state. If your data lives in React Query, SWR, or a simple useState + Context, adding Redux Toolkit adds indirection without benefit. I've seen teams bolt Redux onto a 5-page marketing site — that's over-engineering. Use it when multiple, unrelated components need the same global data, or when you have complex state transitions like a shopping cart or a multi-step form.
Getting Started with Redux Toolkit
The setup is minimal. Install the package and create a store, then wrap your app with the provider. Here's a runnable example:
// store.ts
import { configureStore } from '@reduxjs/toolkit';
import userReducer from './userSlice';
export const store = configureStore({
reducer: {
user: userReducer,
},
});
export type RootState = ReturnType<typeof store.getState>;
export type AppDispatch = typeof store.dispatch;
// main.tsx
import { Provider } from 'react-redux';
import { store } from './store';
ReactDOM.createRoot(document.getElementById('root')!).render(
<Provider store={store}>
<App />
</Provider>
);
That's it. No middleware setup, no devtools configuration — configureStore wires up Redux DevTools and thunk middleware automatically. You can now use useSelector and useDispatch in any component.
Core Redux Toolkit Concepts Every Developer Should Know
1. createSlice — The Heart of the Toolkit
createSlice auto-generates action creators and action types from your reducer functions. You write reducers with mutable-looking syntax thanks to Immer, and the toolkit handles immutability behind the scenes.
// userSlice.ts
import { createSlice, PayloadAction } from '@reduxjs/toolkit';
interface UserState {
name: string;
email: string;
isLoggedIn: boolean;
}
const initialState: UserState = {
name: '',
email: '',
isLoggedIn: false,
};
const userSlice = createSlice({
name: 'user',
initialState,
reducers: {
login(state, action: PayloadAction<{ name: string; email: string }>) {
state.name = action.payload.name;
state.email = action.payload.email;
state.isLoggedIn = true;
},
logout(state) {
state.name = '';
state.email = '';
state.isLoggedIn = false;
},
},
});
export const { login, logout } = userSlice.actions;
export default userSlice.reducer;
You never write return { ...state, name: action.payload } — Immer does that for you.
2. createAsyncThunk — Handling Async State
For API calls, createAsyncThunk generates three action types: pending, fulfilled, and rejected. You handle each in the slice's extraReducers.
import { createAsyncThunk, createSlice } from '@reduxjs/toolkit';
export const fetchUser = createAsyncThunk(
'user/fetch',
async (userId: string) => {
const res = await fetch(`/api/users/${userId}`);
return res.json();
}
);
const userSlice = createSlice({
name: 'user',
initialState: { data: null, status: 'idle', error: null },
reducers: {},
extraReducers: (builder) => {
builder
.addCase(fetchUser.pending, (state) => { state.status = 'loading'; })
.addCase(fetchUser.fulfilled, (state, action) => {
state.status = 'succeeded';
state.data = action.payload;
})
.addCase(fetchUser.rejected, (state, action) => {
state.status = 'failed';
state.error = action.error.message;
});
},
});
This gives you a consistent pattern for every API call — no more ad-hoc loading flags scattered across components.
3. createSelector — Memoized Derived Data
Use createSelector from Reselect (re-exported by Redux Toolkit) to compute derived data efficiently. It only recalculates when the input selectors change.
import { createSelector } from '@reduxjs/toolkit';
const selectUser = (state: RootState) => state.user;
export const selectUserDisplayName = createSelector(
[selectUser],
(user) => user.isLoggedIn ? `${user.name} (${user.email})` : 'Guest'
);
This prevents expensive calculations from running on every state change.
Common Redux Toolkit Mistakes and How to Fix Them
Mistake 1: Mutating state outside of createSlice reducers. Immer only works inside the reducer functions. If you try to mutate state in a thunk or a component, you'll get unpredictable behavior. Fix: always treat state as read-only outside of createSlice, and dispatch actions to change it.
Mistake 2: Putting non-serializable values in the state. Redux DevTools and time-travel debugging rely on serializable state. If you store Date objects, class instances, or functions, you'll break that tooling and potentially cause subtle bugs. Fix: store primitive values and plain objects; convert dates to ISO strings before dispatching.
Mistake 3: Over-using Redux for server state. I've seen teams store every API response in Redux, duplicating what React Query already caches. This leads to stale data and complex cache invalidation logic. Fix: keep server data in a dedicated data-fetching library, and use Redux only for client-side global state like auth tokens, UI toggles, or form wizards.
When Should You Use Redux Toolkit?
Use Redux Toolkit when you have global client state that's shared across many components and changes frequently — think user authentication, shopping cart items, or a real-time dashboard with multiple widgets that sync. It's also ideal when you need predictable state transitions, like an undo/redo feature or a complex wizard with steps. If your state is local to a single component or its children, useState or useReducer is sufficient. And if your primary need is server data fetching, use React Query or SWR instead. For most full-stack apps, a combination works best: React Query for server state, Redux Toolkit for client state.
Redux Toolkit in Production
Tip 1: Use TypeScript with strict mode. The toolkit's types are excellent, and strict mode catches mistakes at compile time. Define RootState and AppDispatch types as shown earlier, and use typed hooks (useAppDispatch, useAppSelector) to avoid repeating type annotations.
Tip 2: Split slices by domain, not by UI. Organize your slices folder by feature (e.g., auth, cart, notifications), not by component. This keeps related state together and makes it easier to test and maintain.
Tip 3: Use createListenerMiddleware for side effects. Instead of putting console.log or analytics calls inside reducers (which should be pure), use the listener middleware to react to state changes. This keeps your reducers testable and your side effects centralized.
Tip 4: Lazy-load slices with injectReducer. For large apps, you don't want to load all reducers upfront. Redux Toolkit supports dynamic reducer injection — load a slice only when a route or feature mounts. This reduces initial bundle size and improves load time.
The one concrete takeaway: start every new Redux project with createSlice and configureStore, and keep server data out of Redux — that single decision will save you hundreds of hours of debugging over a project's lifetime.