Releases: reduxjs/redux-toolkit
v2.0.0-rc.1
This release candidate updates to the latest Redux 5.0 RC to use its exported isAction and isPlainObject util methods, renames the pre-minified ESM production build to redux-toolkit.browser.mjs and drops the ESM precompiled dev build, and updates build tooling.
Note that we hope to release Redux Toolkit 2.0, Redux core 5.0, and React-Redux 9.0 by the start of December! (If we don't hit that, we'll aim for January, after the holidays.)
See the preview Redux Toolkit 2.0 + Redux core 5.0 Migration Guide for an overview of breaking changes in RTK 2.0 and Redux core.
The 2.0 integration branch contains the docs preview for the 2.0 changes. Not all changes are documented yet, but you can see API reference pages for most of the new features here:
npm install @reduxjs/toolkit@next
yarn add @reduxjs/toolkit@nextChangelog
isAction Predicate
We recently added an isAction predicate to RTK, then realized it's better suited for the Redux core. This can be used anywhere you have a value that could be a Redux action object, and you need to check if it is actually an action. This is specifically useful for use with the updated Redux middleware TS types, where the default value is now unknown and you need to use a type guard to tell TS that the current value is actually an action.
This is now exported from the Redux core, and re-exported from RTK, which also uses it internally to avoid duplicating that logic.
We've also exported the isPlainObject util that's been in the Redux codebase for years as well.
ESM Build Artifacts
We previously dropped the UMD build artifacts in an earlier alpha, but added ESM build artifacts that are pre-compiled to remove the process.env.NODE_ENV definitions, with the intent that these are useable as <script type="module"> tags in the browser. Those were previously named as redux-toolkit.modern.development.mjs and redux-toolkit.modern.production.mjs.
We've renamed the production artifact to redux-toolkit.browser.mjs to be consistent with the other Redux-related packages, and removed the dev build artifact on the grounds that we don't think there's enough likely usage to include it. If you think you would specifically benefit from having an ESM browser-compatible dev artifact, let us know!
What's Changed
- Merge master into
v2.0-integrationby @markerikson in #3903 - Update build tooling for 2.0 by @markerikson in #3902
- Update to Redux core v5 rc1 and replace isAction/isPlainObject with core counterparts by @EskiMojo14 in #3904
- Drop "ESM modern dev" build and rename "ESM prod" to "browser" by @markerikson in #3905
- fix isFSA import and avoid unnecessary type param by @EskiMojo14 in #3906
Full Changelog: v2.0.0-rc.0...v2.0.0-rc.1
Contributors
Assets 2
v2.0.0-rc.0
This release candidate modifies the approach for defining async thunks inside of createSlice, and improves several bits of usage and implementation around selectors.
Note that we hope to release Redux Toolkit 2.0, Redux core 5.0, and React-Redux 9.0 by the start of December! (If we don't hit that, we'll aim for January, after the holidays.)
See the preview Redux Toolkit 2.0 + Redux core 5.0 Migration Guide for an overview of breaking changes in RTK 2.0 and Redux core.
The 2.0 integration branch contains the docs preview for the 2.0 changes. Not all changes are documented yet, but you can see API reference pages for most of the new features here:
npm install @reduxjs/toolkit@next
yarn add @reduxjs/toolkit@nextChangelog
Async Thunk and createSlice changes
In earlier alphas, we added the ability to define async thunks directly inside of createSlice.reducers, using a callback syntax. However, that meant that createSlice had a hard dependency on createAsyncThunk, and importing createSlice would always include createAsyncThunk in an app bundle even if it wasn't being used.
In practice, we expect that most RTK users will use createAsyncThunk, either directly or as part of RTK Query. But, we take bundle size seriously, and didn't want to force all uses of createSlice to add the 2K for createAsyncThunk to a bundle if it isn't actually being used.
Since we expect that defining thunks inside of createSlice is a less-common use case, we've settled on a compromise. The standard createSlice method does not support calling create.asyncThunk() inside even if you use the callback syntax. Instead, you need to call buildCreateSlice() to create a customized version of createSlice with the async thunk capabilities built in, and use that:
const createSliceWithThunks = buildCreateSlice({
creators: { asyncThunk: asyncThunkCreator },
})
const todosSlice = createSliceWithThunks ({
name: 'todos',
initialState: {
loading: false,
todos: [],
error: null,
} as TodoState,
reducers: (create) => ({
// A normal "case reducer", same as always
deleteTodo: create.reducer((state, action: PayloadAction<number>) => {
state.todos.splice(action.payload, 1)
}),
// A case reducer with a "prepare callback" to customize the action
addTodo: create.preparedReducer(
(text: string) => {
const id = nanoid()
return { payload: { id, text } }
},
// action type is inferred from prepare callback
(state, action) => {
state.todos.push(action.payload)
}
),
// An async thunk
fetchTodo: create.asyncThunk(
// Async payload function as the first argument
async (id: string, thunkApi) => {
const res = await fetch(`myApi/todos?id=${id}`)
return (await res.json()) as Item
},
// An object containing `{pending?, rejected?, fulfilled?, settled?, options?}` second
{
pending: (state) => {
state.loading = true
},
rejected: (state, action) => {
state.error = action.payload ?? action.error
},
fulfilled: (state, action) => {
state.todos.push(action.payload)
},
// settled is called for both rejected and fulfilled actions
settled: (state, action) => {
state.loading = false
},
}
),
}),
})Selector Changes
createSlice now adds a selectSlice field to all slice objects. This simple selector assumes that the slice has been added at rootState[slice.name] (or rootState[slice.reducerPath] if defined). This is useful for basic lookups of the slice's state.
entityAdapter.getSelectors() now accepts alternate selector creators with customized memoization options.
What's Changed
- [RTK v2.0] output selector fields are currently missing in selector functions created using
createDraftSafeSelector. by @aryaemami59 in #3722 - createDynamicMiddleware bike shedding by @EskiMojo14 in #3763
- Allow passing selector creators with different memoize options to getSelectors by @EskiMojo14 in #3833
- Add selectSlice to slice instance by @EskiMojo14 in #3838
- Throw an error if ApiProvider is nested inside a normal Provider. by @EskiMojo14 in #3855
- Create standardised methods of modifying reducer handler context. by @EskiMojo14 in #3872
- Require calling buildCreateSlice to use create.asyncThunk by @EskiMojo14 in #3867
- Restore the toString override, but keep it out of the docs. by @EskiMojo14 in #3877
- Selector housekeeping - emplace and unwrapped by @EskiMojo14 in #3878
- Update deps for RC by @markerikson in #3883
Full Changelog: v2.0.0-beta.4...v2.0.0-rc.0
v2.0.0-beta.4
This beta release updates RTK Query to fix issues around cache entry behavior when subscription: false is used or with multiple lazy queries in progress, alters RTK Query's tag invalidation behavior to better handle cases where multiple invalidations may happen in sequence, rewrites RTK Query's internals to improve performance around subscription data syncing, and updates Reselect to the latest 5.0.0-beta.0.
npm i @reduxjs/toolkit@beta
yarn add @reduxjs/toolkit@betaThe 2.0 integration branch contains the docs preview for the 2.0 changes. Not all changes are documented yet, but you can see API reference pages for most of the new features here:
Changelog
RTK Query Behavior Changes
We've had a number of reports where RTK Query had issues around usage of dispatch(endpoint.initiate(arg, {subscription: false})). There were also reports that multiple triggered lazy queries were resolving the promises at the wrong time. Both of these had the same underlying issue, which was that RTKQ wasn't tracking cache entries in these cases (intentionally). We've reworked the logic to always track cache entries (and remove them as needed), which should resolve those behavior issues.
We also have had issues raised about trying to run multiple mutations in a row and how tag invalidation behaves. RTKQ now has internal logic to delay tag invalidation briefly, to allow multiple invalidations to get handled together. This is controlled by a new invalidationBehavior: 'immediate' | 'delayed' flag on createApi. The new default behavior is 'delayed'. Set it to 'immediate' to revert to the behavior in RTK 1.9.
In RTK 1.9, we reworked RTK Query's internals to keep most of the subscription status inside the RTKQ middleware. The values are still synced to the Redux store state, but this is primarily for display by the Redux DevTools "RTK Query" panel. Related to the cache entry changes above, we've optimized how often those values get synced to the Redux state for perf.
Other Changes
We've updated the Reselect dependency to Reselect 5.0.0-beta.0, which adds the ability to pass memoizer functions and options directly to createSelector.
The new create.asyncThunk() builder inside of createSlice can now be given a settled reducer, which will run when the thunk promise either fulfills or rejects.
What's Changed
- Add settled matcher for createAsyncThunk by @EskiMojo14 in #3768
- Rewrite RTKQ internal subscription lookups and subscription syncing by @markerikson in #3824
- keep subscription on data while query is running by @phryneas in #3709
- Stop re-exporting
autotrackMemoizeby @markerikson in #3831 - Delayed tag invalidations by @GeorchW in #3116
- Bump Reselect to 5.0-beta by @markerikson in #3832
Full Changelog: v2.0.0-beta.3...v2.0.0-beta.4
Contributors
Assets 2
v2.0.0-beta.3
This beta release updates configureStore to remove the deprecated option of passing an array for middleware, improves the createEntityAdapter types to improve compatibility, updates deps to use the latest React-Redux beta, and optimizes the TS compile perf for RTKQ hooks.
npm i @reduxjs/toolkit@beta
yarn add @reduxjs/toolkit@betaThe 2.0 integration branch contains the docs preview for the 2.0 changes. Not all changes are documented yet, but you can see API reference pages for most of the new features here:
Changelog
configureStore.middleware Option Must Be A Callback
Since the beginning, configureStore has accepted a direct array value as the middleware option. However, providing an array directly prevents configureStore from calling getDefaultMiddleware(). So, middleware: [myMiddleware]` means there is no thunk middleware added (or any of the dev-mode checks).
This is a footgun, and we've had numerous users accidentally do this and cause their apps to fail because the default middleware never got configured.
We already had made the enhancers option only accept the callback form, so we've done the same thing for middleware.
If for some reason you still want to replace all of the built-in middleware, do so by returning an array from the callback:
const store = configureStore({
reducer,
middleware: (getDefaultMiddleware) => {
// WARNING: this means that _none_ of the default middleware are added!
return [myMiddleware];
// or for correct TS inference, use:
// return new Tuple(myMiddleware)
}
})But note that we consistently recommend not replacing the default middleware entirely, and that you should use return getDefaultMiddleware().concat(myMiddleware).
TS Updates
The types for createEntityAdapter have been reworked for better compat with Immer drafts.
The RTK Query types for generating React hooks have been optimized for much faster TS compilation perf (~60% improvement in one synthetic example app).
Other Changes
RTK Query's custom React hooks option now checks at runtime that all 3 hooks have been provided.
A new codemod is now available as part of the @reduxjs/rtk-codemods package that will convert a given createSlice call to the new "create callback" notation, which is primarily used for adding thunks inside of createSlice. Unlike the other codemods for replacing the obsolete/removed object syntax in createReducer and createSlice, this is purely optional.
What's Changed
- Update CI examples to use latest betas and add tests by @markerikson in #3746
- Update MSW to 1.3.2, React-Redux to 2.0-beta.0, and log Playwright by @markerikson in #3757
- Work around known TS bug with type inference by @markerikson in #3761
- Remove middleware array option by @EskiMojo14 in #3760
- warn for and migrate old options and require all hooks by @EskiMojo14 in #3549
- [RED-24] Feature/entity adapter draftable entity state by @Olesj-Bilous in #3669
- write create callback codemod by @EskiMojo14 in #3525
- Rewrite HooksWithUniqueNames type (v2.0) by @EskiMojo14 in #3767
Full Changelog: v2.0.0-beta.2...v2.0.0-beta.3
Contributors
Assets 2
v1.9.7
This bugfix release rewrites the RTKQ hook TS types to significantly improve TS perf.
Changelog
RTKQ TS Perf
A number of users had reported that Intellisense for RTKQ API objects was extremely slow (multiple seconds) - see discussion in #3214 . We did some perf investigation on user-provided examples, and concluded that the biggest factor to slow RTKQ TS perf was the calculation of hook names like useGetPokemonQuery, which was generating a large TS union of types.
We've rewritten that hook names type calculation to use mapped types and a couple of intersections. In a specific user-provided stress test repo, it dropped TS calculation time by 60% (2600ms to 1000ms).
There's more potential work we can do to improve things, but this seems like a major perf improvement worth shipping now.
What's Changed
- chore: Switch 4.9.2-rc to 4.9.5 since 4.9.5 has been released in TypeScript by @kahirokunn in #3772
- Copy of "Work around known TS bug with type inference #3761" by @julian-ford in #3777
- Rework named hooks type (v1.9) by @EskiMojo14 in #3769
Full Changelog: v1.9.6...v1.9.7
Contributors
Assets 2
v2.0.0-beta.2
This beta release updates the build step to extract error messages and optimizes internal imports in RTK Query for smaller production bundle sizes, adds a selectCachedArgsForQuery util, and includes all changes in v1.9.6
npm i @reduxjs/toolkit@beta
yarn add @reduxjs/toolkit@betaThe 2.0 integration branch contains the docs preview for the 2.0 changes. Not all changes are documented yet, but you can see API reference pages for most of the new features here:
Changelog
Bundle Size Optimizations
Redux 4.1.0 optimized its bundle size by extracting error message strings out of production builds, based on React's approach. We've applied the same technique to RTK. This saves about 1000 bytes from prod bundles (actual benefits will depend on which imports are being used).
We also noted that ESBuild does not deduplicate imports when it bundles source files, and this was causing RTK Query's bundle to contain a dozen references to import { } from "@reduxjs/toolkit", including some of the same methods. Manually deduplicating those saves about 600 bytes off the production RTKQ artifact.
Other Changes
We've added a selectCachedArgsForQuery util selector that will return the saved arguments that were used for a given cache entry.
This also includes all of the changes in v1.9.6.
What's Changed
- Switch advised syntax for create.reducer by @EskiMojo14 in #3702
- Add selectCachedArgsForQuery util by @EskiMojo14 in #3547
- Optimize bundles for RTK 2.0 by @markerikson in #3740
- Merge
1.9.6intov2.0-integrationby @markerikson in #3743
Full Changelog: v2.0.0-beta.1...v2.0.0-beta.2
Contributors
Assets 2
v1.9.6
This bugfix release adds a new dev-mode middleware to catch accidentally dispatching an action creator, adds a new listener middleware option around waiting for forks, adds a new option to update provided tags when updateQueryData is used, reworks internal types to better handle uses with TS declaration output, and fixes a variety of small issues.
Changelog
Action Creator Dev Check Middleware
RTK already includes dev-mode middleware that check for the common mistakes of accidentally mutating state and putting non-serializable values into state or actions.
Over the years we've also seen a semi-frequent error where users accidentally pass an action creator reference to dispatch, instead of calling it and dispatching the action it returns.
We've added another dev-mode middleware that specifically catches this error and warns about it.
Additional Options
The listener middleware's listenerApi.fork() method now has an optional autoJoin flag that can be used to keep the effect from finishing until all active forked tasks have completed.
updateQueryData now has an updateProvidedTags option that will force a recalculation of that endpoint's provided tags. It currently defaults to false, and we'll likely turn that to true in the next major.
Other Fixes
The builder.addCase method now throws an error if a type string is empty.
fetchBaseQuery now uses an alternate method to clone the original Request in order to work around an obscure Chrome bug.
The immutability middleware logic was tweaked to avoid a potential stack overflow.
Types Changes
The internal type imports have been reworked to try to fix "type portability" issues when used in combination with TS declaration outputs.
A couple additional types were exported to help with wrapping createAsyncThunk.
What's Changed
- create action creator middleware by @EskiMojo14 in #3414
- Implement auto fork joining by @ericanderson in #3407
- types: make it easier to wrap createAsyncThunk by @shrouxm in #3393
- Fixed Stackoverflow bug if children prop is a ref to root/parent object by @cheprasov in #3428
- Fix TransformedResponse type to unwrap promise by @EskiMojo14 in #3500
- Throw error when type is empty in builder.addCase by @chawes13 in #3572
- [RED-23] fix: Updated type references to resolve portable types issue by @tdurnford in #3728
- add option to update provided tags by @dutzi in #3255
- [RED-26] Remove Request.clone() usage in fetchBaseQuery by @alex-vukov in #3720
- Try working around TS 4.1 mismatch by @markerikson in #3739
Full Changelog: v1.9.5...v1.9.6
Contributors
Assets 2
v2.0.0-beta.1
This beta release updates the build and packaging setup to improve TS and ESM compatibility, fixes several TS issues, and updates to the latest React-Redux and Redux-Thunk deps.
npm i @reduxjs/toolkit@beta
yarn add @reduxjs/toolkit@betaThe 2.0 integration branch contains the docs preview for the 2.0 changes. Not all changes are documented yet, but you can see API reference pages for most of the new features here:
Build and TS Updates
We've made several tweaks to the packaging to improve compatibility for ESM and TS typedef definitions, which should fix some issues that were reported with beta.0.
We also fixed several assorted TS issues that were affecting users in specific edge cases.
Other Changes
We removed the AbortController polyfill from createAsyncThunk, saving some bytes.
We've updated deps to [email protected] and [email protected].
What's Changed
- fix syntax for users with noPropertyAccessFromIndexSignature enabled by @evertbouw in #3495
- Fix multiple TS build and packaging issues by @markerikson in #3672
- fix: Default export of the module has or is using private name type error when using latest alpha/beta by @eric-crowell in #3605
- RTK Query: resolve type portability issues by @markerikson in #3678
- fix(RTKQuery React): Resolved declare module pathing for Node16 by @eric-crowell in #3592
- fix(2448): remove abort controller polyfill by @JulienKode in #2518
- Update thunk and React-Redux deps by @markerikson in #3679
Full Changelog: v2.0.0-beta.0...v2.0.0-beta.1
Contributors
Assets 2
v2.0.0-beta.0
This beta release updates many of our TS types for improved type safety and behavior, updates entityAdapter.getSelectors() to accept a createSelector option, depends on the latest [email protected] release, and includes all prior changes from the 2.0 alphas. This release has breaking changes.
npm i @reduxjs/toolkit@next
yarn add @reduxjs/toolkit@nextThe 2.0 integration branch contains the docs preview for the 2.0 changes. Not all changes are documented yet, but you can see API reference pages for most of the new features here:
Changelog
Store Configuration Tweaks and Type Safety
We've seen many cases where users passing the middleware parameter to configureStore have tried spreading the array returned by getDefaultMiddleware(), or passed an alternate plain array. This unfortunately loses the exact TS types from the individual middleware, and often causes TS problems down the road (such as dispatch being typed as Dispatch<AnyAction> and not knowing about thunks).
getDefaultMiddleware() already used an internal MiddlewareArray class, an Array subclass that had strongly typed .concat/prepend() methods to correctly capture and retain the middleware types.
We've renamed that type to Tuple, and configureStore's TS types now require that you must use Tuple if you want to pass your own array of middleware:
import { configureStore, Tuple } from '@reduxjs/toolkit'
configureStore({
reducer: rootReducer,
middleware: new Tuple(additionalMiddleware, logger),
})(Note that this has no effect if you're using RTK with plain JS, and you could still pass a plain array here.)
Similarly, the enhancers field used to accept an array directly. It now is a callback that receives a getDefaultEnhancers method, equivalent to getDefaultMiddleware():
const store = configureStore({
reducer,
middleware: (getDefaultMiddleware) => getDefaultMiddleware().concat(logger),
enhancers: (getDefaultEnhancers) =>
getDefaultEnhancers({
autoBatch: false,
}).concat(batchedSubscribe(debounceNotify)),
})It too expects a Tuple return value if you're using TS.
Entity Adapter Updates
entityAdapter.getSelectors() now accepts an options object as its second argument. This allows you to pass in your own preferred createSelector method, which will be used to memoize the generated selectors. This could be useful if you want to use one of Reselect's new alternate memoizers, or some other memoization library with an equivalent signature.
createEntityAdapter now has an Id generic argument, which will be used to strongly type the item IDs anywhere those are exposed. Previously, the ID field type was always string | number. TS will now try to infer the exact type from either the .id field of your entity type, or the selectId return type. You could also fall back to passing that generic type directly.
The .entities lookup table is now defined to use a standard TS Record<Id, MyEntityType>, which assumes that each item lookup exists by default. Previously, it used a Dictionary<MyEntityType> type, which assumed the result was MyEntityType | undefined. The Dictionary type has been removed.
If you prefer to assume that the lookups might be undefined, use TypeScript's noUncheckedIndexedAccess configuration option to control that.
New UnknownAction Type
The Redux core TS types have always exported an AnyAction type, which is defined to have {type: string} and treat any other field as any. This makes it easy to write uses like console.log(action.whatever), but unfortunately does not provide any meaningful type safety.
We now export an UnknownAction type, which treats all fields other than action.type as unknown. This encourages users to write type guards that check the action object and assert its specific TS type. Inside of those checks, you can access a field with better type safety.
UnknownAction is now the default any place in the Redux and RTK source that expects an action object.
AnyAction still exists for compatibility, but has been marked as deprecated.
Note that Redux Toolkit's action creators have a .match() method that acts as a useful type guard:
if (todoAdded.match(someUnknownAction)) {
// action is now typed as a PayloadAction<Todo>
}Earlier Alpha Changes
Summarizing the changes from earlier alphas:
New Features
combineSlicesAPI with built-in support for slice reducer injection for code-splittingselectorsfield increateSlice- Callback form of
createSlice.reducers, which allows defining thunks insidecreateSlice - "Dynamic middleware" middleware
configureStoreaddsautoBatchEnhancerby default- Reselect v5 runs selectors an additional time on first call in dev to check for improper memoization, and includes new optional
autotrackandweakmapmemoizers with different tradeoffs
Breaking Changes
- Object argument for
createReducerandcreateSlice.extraReducershas been removed - Packaging converted to have full ESM/CJS compatibility
- Dropped UMD build artifacts
- JS build output is now "modern" and not transpiled for IE11 compatibility
- Updated to Immer 10, and dropped the legacy ES5 compat option
- Updated Redux core dep to
5.0-beta actionCreator.toString()override removed (although we're reconsidering this)- Standalone
getDefaultMiddlewareremoved - Other deprecated fields removed
What's Changed
- Add Id type parameter in createEntityAdapter by @Matt-Ord in #3187
- Require usage of Tuple in TS by @EskiMojo14 in #3460
- Require that enhancers is a callback by @EskiMojo14 in #3461
- fix invalid createEntityAdapter call by @EskiMojo14 in #3490
- Use Record<EntityId, T> instead of Dictionary by @EskiMojo14 in #3424
- Fix inference for reducers without actions specified by @EskiMojo14 in #3475
- Prefer UnknownAction and Action to AnyAction by @EskiMojo14 in #3363
- Allow passing a
createSelectorinstance to adapter.getSelectors by @EskiMojo14 in #3481
Full Changelog: v2.0.0-alpha.6...v2.0.0-beta.0
v2.0.0-alpha.6
This is an alpha release for Redux Toolkit 2.0, and has breaking changes. This release updates createSlice to allow declaring thunks directly inside the reducers field using a callback syntax, adds a new "dynamic middleware" middleware, updates configureStore to add the autoBatchEnhancer by default, removes the .toString() override from action creators, updates Reselect from v4.x to v5.0-alpha, updates the Redux core to v5.0-alpha.6, and includes the latest changes from 1.9.x.
npm i @reduxjs/toolkit@alpha
yarn add @reduxjs/toolkit@alphaThe 2.0 integration branch contains the docs preview for the 2.0 changes. Not all changes are documented yet, but you can see API reference pages for some of the new features here:
Changelog
Declaring Thunks Inside createSlice.reducers
One of the oldest feature requests we've had is the ability to declare thunks directly inside of createSlice. Until now, you've always had to declare them separately, give the thunk a string action prefix, and handle the actions via createSlice.extraReducers:
// Declare the thunk separately
const fetchUserById = createAsyncThunk(
'users/fetchByIdStatus',
async (userId: number, thunkAPI) => {
const response = await userAPI.fetchById(userId)
return response.data
}
)
const usersSlice = createSlice({
name: 'users',
initialState,
reducers: {
// standard reducer logic, with auto-generated action types per reducer
},
extraReducers: (builder) => {
// Add reducers for additional action types here, and handle loading state as needed
builder.addCase(fetchUserById.fulfilled, (state, action) => {
state.entities.push(action.payload)
})
},
})Many users have told us that this separation feels awkward.
We've wanted to include a way to define thunks directly inside of createSlice, and have played around with various prototypes. There were always two major blocking issues, and a secondary concern:
1 It wasn't clear what the syntax for declaring a thunk inside should look like.
2. Thunks have access to getState and dispatch, but the RootState and AppDispatch types are normally inferred from the store, which in turn infers it from the slice state types. Declaring thunks inside createSlice would cause circular type inference errors, as the store needs the slice types but the slice needs the store types. We weren't willing to ship an API that would work okay for our JS users but not for our TS users, especially since we want people to use TS with RTK.
3. You can't do synchronous conditional imports in ES modules, and there's no good way to make the createAsyncThunk import optional. Either createSlice always depends on it (and adds that to the bundle size), or it can't use createAsyncThunk at all.
We've settled on these compromises:
- You can declare thunks inside of
createSlice.reducers, by using a "creator callback" syntax for thereducersfield that is similar to thebuildcallback syntax in RTK Query'screateApi(using typed functions to create fields in an object). Doing this does look a bit different than the existing "object" syntax for thereducersfield, but is still fairly similar. - You can customize some of the types for thunks inside of
createSlice, but you cannot customize thestateordispatchtypes. If those are needed, you can manually do anascast, likegetState() as RootState. createSlicedoes now always depend oncreateAsyncThunk, so thecreateAsyncThunkimplementation will get added to the bundle.
In practice, we hope these are reasonable tradeoffs. Creating thunks inside of createSlice has been widely asked for, so we think it's an API that will see usage. If the TS customization options are a limitation, you can still declare thunks outside of createSlice as always, and most async thunks don't need dispatch or getState - they just fetch data and return. And finally, createAsyncThunk is already being used in many apps, either directly or as part of RTK Query, so in that case there's no additional bundle size increase - you've already paid that cost.
Here's what the new callback syntax looks like:
const todosSlice = createSlice({
name: 'todos',
initialState: {
loading: false,
todos: [],
} as TodoState,
reducers: (create) => ({
// A normal "case reducer", same as always
deleteTodo: create.reducer((state, action: PayloadAction<number>) => {
state.todos.splice(action.payload, 1)
}),
// A case reducer with a "prepare callback" to customize the action
addTodo: create.preparedReducer(
(text: string) => {
const id = nanoid()
return { payload: { id, text } }
},
// action type is inferred from prepare callback
(state, action) => {
state.todos.push(action.payload)
}
),
// An async thunk
fetchTodo: create.asyncThunk(
// Async payload function as the first argument
async (id: string, thunkApi) => {
const res = await fetch(`myApi/todos?id=${id}`)
return (await res.json()) as Item
},
// An object containing `{pending?, rejected?, fulfilled?, options?}` second
{
pending: (state) => {
state.loading = true
},
rejected: (state, action) => {
state.loading = false
},
fulfilled: (state, action) => {
state.loading = false
state.todos.push(action.payload)
},
}
),
}),
})
// `addTodo` and `deleteTodo` are normal action creators.
// `fetchTodo` is the async thunk
export const { addTodo, deleteTodo, fetchTodo } = todosSlice.actions"Dynamic Middleware" Middleware
A Redux store's middleware pipeline is fixed at store creation time and can't be changed later. We have seen ecosystem libraries that tried to allow dynamically adding and removing middleware, potentially useful for things like code splitting.
This is a relatively niche use case, but we've built our own version of a "dynamic middleware" middleware. Add it to the Redux store at setup time, and it lets you add and remove middleware later at runtime. It also comes with a React hook integration that will automatically add a middleware to the store and return the updated dispatch method.
import { createDynamicMiddleware, configureStore } from '@reduxjs/toolkit'
const dynamicMiddleware = createDynamicMiddleware()
const store = configureStore({
reducer: {
todos: todosReducer,
},
middleware: (getDefaultMiddleware) =>
getDefaultMiddleware().prepend(dynamicMiddleware.middleware),
})
// later
dynamicMiddleware.addMiddleware(someOtherMiddleware)Store Adds autoBatchEnhancer By Default
In v1.9.0, we added a new autoBatchEnhancer that delays notifying subscribers briefly when multiple "low-priority" actions are dispatched in a row. This improves perf, as UI updates are typically the most expensive part of the update process. RTK Query marks most of its own internal actions as "low-pri" by default, but you have to have the autoBatchEnhancer added to the store to benefit from that.
We've updated configureStore to add the autoBatchEnhancer to the store setup by default, so that users can benefit from the improved perf without needing to manually tweak the store config themselves.
configureStore now also accepts a callback for the enhancers option that receives a getDefaultEnhancers() param, equivalent to how the middleware callback receives getDefaultMiddleware():
const store = configureStore({
reducer: rootReducer,
middleware: (getDefaultMiddleware) =>
getDefaultMiddleware().concat(loggerMiddleware),
preloadedState,
enhancers: (getDefaultEnhancers) =>
getDefaultEnhancers().concat(anotherEnhancer),
})Deprecation Removals
When we first released the early alphas of RTK, one of the main selling points was that you could reuse RTK's action creators as "computed key" fields in the object argument to createReducer, like:
const todoAdded = createAction("todos/todoAdded");
const reducer = createReducer([], {
[todoAdded]: (state, action) => {}
})This was possible because createAction overrides the fn.toString() field on these action creators to return the action type string. When JS sees the function, it implicitly calls todoAdded.toString(), which returns "todos/todoAdded", and that string is used as the key.
While this capability was useful early on, it's not useful today. Most users never call createAction, because createSlice automatically generates action creators. Additionally, it has no TS type safety. TS only sees that the key is a string, and has no idea what the correct TS type for action is. We later created the "builder callback" syntax for both createReducer and createSlice.extraReducers, started teaching that as the default, and removed the "object" argument to both of those in an earlier RTK 2.0 alpha.
Because of this, we've now removed the fn.toString() override. If you need to access the type string from an action creator function, those still have a .type field attached:
const todoAdded = createAction("todos/todoAdded");
console.log(todoAdded.type) // "todos/todoAdded"We've also removed the standalone export of getDefaultMiddleware, which has been deprecated ever since we added the callback for the `configureStore.middlewa...