Redux Toolkit: what the official Redux toolset actually bundles

The three Redux complaints Redux Toolkit was built to answer

The README states the package was created to address three specific complaints: configuring a store is too complicated, too many packages are needed to do anything useful, and Redux requires too much boilerplate. That framing matters because it tells you the target audience is not people who have never heard of Redux. It is people who already decided they want a Redux store and are tired of wiring it by hand.

The package is opinionated about that setup and deliberately narrow about everything else. The README says it does not address reusable encapsulated Redux modules, folder or file structures, or managing entity relationships in the store. So it will not tell you how to lay out a large codebase. It gives you the store, the reducers, the action creators and the middleware defaults, and leaves architecture to you.

That scope is the honest part of the pitch. If you want a framework that decides your file layout, this is not it. If you want the Redux store setup to stop being the hard part, the bundled APIs are aimed directly at that.

configureStore, createSlice and the immer-based reducer model

The core mechanism is a set of APIs that wrap the lower-level Redux primitives. configureStore() wraps createStore, combines your slice reducers automatically, accepts whatever middleware you supply, includes redux-thunk by default, and enables the Redux DevTools Extension. createReducer() takes a lookup table of action types mapped to case reducer functions instead of a switch statement, and uses the immer library so you can write updates that look mutable, such as state.todos[3].completed = true, while producing immutable state.

createSlice() is the combination point. It accepts an object of reducer functions, a slice name and an initial state value, then generates the slice reducer together with the matching action creators and action types. That single call is what removes most of the boilerplate the README complains about: no separate action type constants, no hand-written action creators, no switch block.

Around that core sit several optional pieces. combineSlices() merges multiple slices into one reducer and allows lazy loading of slices after initialisation. createListenerMiddleware() lets you define listener entries with an effect callback plus a condition for when that callback runs, based on dispatched actions or state changes; the README describes it as a lightweight alternative to async middleware such as sagas and observables. createAsyncThunk() takes an action type string and a promise-returning function, and dispatches pending, resolved and rejected action types from that promise. createEntityAdapter() generates reusable reducers and selectors for normalized data. createSelector() from Reselect is re-exported so you do not add a second dependency for memoized selectors.

Installing Redux Toolkit and defining a first slice

For a new React app the README points at two templates rather than a manual install. The Vite template is cloned with the tiged tool, and the Next.js option uses Next's own with-redux example. For React Native there is an Expo template in the same templates repository.

# Vite with our Redux+TS template
npx tiged reduxjs/redux-templates/packages/vite-template-redux my-app

# Next.js using the `with-redux` template
npx create-next-app --example with-redux my-app

Both templates already have Redux Toolkit and React-Redux configured for the build tool and ship a small example app, so the first thing you see after scaffolding is a working store rather than an empty folder.

For an existing app, the package installs from npm or Yarn under the name @reduxjs/toolkit.

# NPM
npm install @reduxjs/toolkit

# Yarn
yarn add @reduxjs/toolkit

The README also notes a precompiled browser ESM build that can be loaded from a script tag with type="module". No-bundler usage additionally needs an import map, because the build imports its dependencies by package name. The README points to the Getting Started docs for a full example rather than reproducing one.

RTK Query lives inside the same package but is reached through a separate entry point. The README shows the import from @reduxjs/toolkit/query, with a React-specific entry point alongside it. It is optional, and the README is explicit that it is intended for data fetching and caching rather than general state.

RTK Query is a second, optional layer with its own mental model

RTK Query is described as purpose-built for one use case: data fetching and caching. It supplies a way to define an API interface layer for your app and is intended to remove hand-written fetching and caching logic for common cases. It is built on top of the Redux Toolkit core and uses Redux internally for its architecture.

The README makes a claim worth taking literally: knowledge of Redux and RTK is not required to use RTK Query. That is a real separation, but it cuts both ways. If you adopt RTK Query without understanding the store underneath, you lose the ability to reason about cache behaviour through the Redux DevTools timeline, which the README says works with RTK Query to traverse and replay request and cache behaviour. The tooling assumes you will look at the store.

The practical consequence is that a team can end up with two overlapping strategies. createAsyncThunk handles request lifecycles by dispatching pending, resolved and rejected actions you write reducers for. RTK Query handles fetching and caching for you. The README presents RTK Query as the option that can eliminate hand-written fetching logic, which reads as a preference for it in the cases it covers, but the package keeps both because not every request fits the caching model.

What Redux Toolkit does not do, and when to pick something else

The stated scope limits are the clearest limitation. There is no opinion on folder structure, no reusable encapsulated module system, and no entity relationship management beyond the normalized collections createEntityAdapter produces. If your problem is organising a large application rather than configuring a store, the package will not solve it.

The second limitation is conceptual weight. Redux Toolkit reduces boilerplate, but it does not remove the reducer and action model. You still describe state transitions as reducers, and you still read state through selectors. For a small app where state lives in a handful of components, that model is more machinery than the problem needs, and the README's own framing, that the package is deliberately limited in scope, does not change that.

Zustand is the alternative that comes up most often, and the difference is structural rather than cosmetic. Zustand is not described in the README, so the comparison has to stay at the level of approach: a store without the reducer and action layer removes the concepts Redux Toolkit is built to make tolerable. If you want Redux's single-store model, devtools timeline and middleware pipeline, Redux Toolkit is the maintained way to get them. If you want state without those concepts, the reducer model is the cost you are choosing not to pay.

Maintenance, releases and the MIT licence

The repository is not archived, and the last push was on 2026-09-21. The most recent release listed is v2.12.0 on 2026-05-15, following v2.11.2 on 2025-12-14 and v2.11.1 on 2025-12-08. That release cadence matters for upgrade planning: the 2.x line has been receiving patch releases between minor versions, so pinning to a minor range and reading the release notes before moving is a reasonable default.

The monorepo is managed with pnpm, with packageManager set to [email protected] in the root package.json. The build and test scripts filter on the @reduxjs/* and @rtk-query/* package names, and the root declares TypeScript 6.0.3 and Vite 8 in devDependencies. None of that affects consumers installing from npm, but it does tell you the published packages are built from a workspace rather than a single flat package.

The licence is MIT, declared in the root package.json and present as a LICENSE file at the repository root. MIT permits commercial use and modification with the copyright notice retained; this is a description of the licence text, not legal advice, and you should read the LICENSE file itself if the terms matter to your organisation.

Editorial conclusion

Adopt Redux Toolkit if you are starting a React, Next.js or React Native app that needs a single predictable store, or if you are migrating hand-written Redux and want configureStore, createSlice and createAsyncThunk to remove the switch statements. Skip it for a small app whose state is local to a few components, and skip it if you want a store that does not require reducers and actions at all. Before committing, verify the current published version on npm, read the configureStore and createSlice API pages at redux-toolkit.js.org, and confirm whether your data fetching belongs in RTK Query or in createAsyncThunk, because that choice shapes the rest of the app.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. README
4. reduxjs/redux-toolkit on GitHub
5. Releases