The official, opinionated, batteries-included toolset for efficient Redux development
MIT License
Bot releases are visible (Hide)
This bugfix release fixes an issue in the recent createEntityAdapter
sorting perf improvements that could (in specific cases) cause Immer to throw an error when trying to read a plain JS value instead of a proxy-wrapped value.
current
may fail if the value is not a draft by @markerikson in https://github.com/reduxjs/redux-toolkit/pull/4412
Full Changelog: https://github.com/reduxjs/redux-toolkit/compare/v2.2.4...v2.2.5
Published by markerikson 5 months ago
This bugfix release improves sorting performance in createEntityAdapter
, shrinks the code size in matcher utilities, fixes assorted issues with query hooks, and makes several TS tweaks.
Users reported in #4252 that the sorting performance of createEntityAdapter
seemed abnormally bad - the provided comparison functions were being called far more times than expected.
Upon investigation, we had a couple of problems. We were always starting from an array that was in insertion order, not the existing sorted order, and that would always require significant effort to re-sort even if there weren't any actual changes to the sorted results. Also, the sorting checks required frequent access to Immer's Proxy-wrapped values, even in cases where all we needed was the plain state values for comparison purposes.
We've reworked the internal sorting logic to always start from the existing sorted array, do reads against a plain value to avoid the Proxy getter overhead where possible, and optimized inserts into existing sorted arrays. This should significantly speed up sorted entity adapter behavior.
We've reworked the internals of the thunk-related matchers to deduplicate some of the logic, shaving a few bytes off the final bundle size.
defaultSerializeQueryArgs
can now handle BigInt
values safely.
The isLoading
flag logic was improved to handle errors when a query hook tries to subscribe.
create.asyncThunk
's types were improved to avoid cases where it might infer any
.
We've made several internal types changes to work correctly with React 19's upcoming types.
The retryCondition
method now receives unknown
as an argument, instead of always assuming the user is using fetchBaseQuery
.
The Reselect dep has been bumped to 5.1.0 to match the expected internal usage of createSelector.withTypes()
.
Context
references to match the new nullable Context
by @aryaemami59 in https://github.com/reduxjs/redux-toolkit/pull/4336
GetThunkAPI
type by @shrouxm in https://github.com/reduxjs/redux-toolkit/pull/4289
React.ReactChild
type by @aryaemami59 in https://github.com/reduxjs/redux-toolkit/pull/4382
JSX
global namespace with React.JSX
by @aryaemami59 in https://github.com/reduxjs/redux-toolkit/pull/4381
useRef
usages to be called with an explicit argument of undefined
. by @aryaemami59 in https://github.com/reduxjs/redux-toolkit/pull/4380
reselect
dependency to 5.1.0 to resolve #4200 by @aryaemami59 in https://github.com/reduxjs/redux-toolkit/pull/4400
initiate()
action for mutations. by @jared-ca in https://github.com/reduxjs/redux-toolkit/pull/4337
Full Changelog: https://github.com/reduxjs/redux-toolkit/compare/v2.2.3...v2.2.4
Published by EskiMojo14 7 months ago
This minor release fixes the types for functions that accept a React Context instance to match the changes in React Redux v9.
.withTypes
by @aryaemami59 in https://github.com/reduxjs/redux-toolkit/pull/4308
Full Changelog: https://github.com/reduxjs/redux-toolkit/compare/v2.2.2...v2.2.3
Published by markerikson 7 months ago
This patch release fixes an incorrect build setting for the legacy-esm
artifacts, and fixes an issue with RTKQ query hooks didn't always remove the cache entries if arguments were changed rapidly.
legacy-esm
Artifact TranspilationThe legacy-esm
build artifacts are intended for use by Webpack 4. Those were supposed to be transpiled to target "es2017"
, but were in fact still set to target "esnext"
- an oversight during the 2.0 development cycle. This release fixes that setting, so those artifacts are now correctly transpiled.
RTKQ query hooks now handle additional actions around argument changes that should result in cache entries being removed.
Additionally, 2.2.1 contained a fix to an incorrectly named type: TypedUseMutationTrigger
is now TypedMutationTrigger
.
Full Changelog: https://github.com/reduxjs/redux-toolkit/compare/v2.2.0...v2.2.2
Published by EskiMojo14 8 months ago
This minor release:
entityAdapter.getInitialState(additionalProps, entities)
to allow prefilling state
entityAdapter.setAll(entityAdapter.getInitialState(additionalProps), entities)
undefined
if no additional properties are desiredcombineSlices
with no static reducers
const combinedReducer = combineSlices().withLazyLoadedSlices<LazyLoadedSlices>()
would have thrown an error'throw'
value for overrideExisting
in injectEndpoints
, which throws an error if a definition is injected with a name which is already usedenhanceEndpoints
LazyLoadedSlices
)action.meta.arg.isPrefetch
value to query thunk actions when prefetchedcli.js
to cli.mjs
by @aryaemami59 in https://github.com/reduxjs/redux-toolkit/pull/4169
withLazyLoadedSlices
by @aryaemami59 in https://github.com/reduxjs/redux-toolkit/pull/4172
overrideExisting
by @ffluk3 in https://github.com/reduxjs/redux-toolkit/pull/4189
tsconfig.json
files of all CodesandBox examples by @aryaemami59 in https://github.com/reduxjs/redux-toolkit/pull/4190
Full Changelog: https://github.com/reduxjs/redux-toolkit/compare/v2.1.0...v2.2.0
Published by EskiMojo14 9 months ago
This minor release:
listenerMiddleware
and createDraftSafeSelector
skipPollingIfUnfocused
option to RTK QuerycreateSelector
instance used by RTK Querythis
valuecreate.asyncThunk
type parametersqueryFn
slistenerMiddleware.withTypes<RootState, AppDispatch>()
method by @aryaemami59 in https://github.com/reduxjs/redux-toolkit/pull/4049
.withTypes
to createDraftSafeSelector
by @aryaemami59 in https://github.com/reduxjs/redux-toolkit/pull/4080
this
in createSlice by @EskiMojo14 in https://github.com/reduxjs/redux-toolkit/pull/4071
tsconfig.typetests.json
to include all TS files by @aryaemami59 in https://github.com/reduxjs/redux-toolkit/pull/4091
composeWithDevTools
spy by @aryaemami59 in https://github.com/reduxjs/redux-toolkit/pull/4093
Full Changelog: https://github.com/reduxjs/redux-toolkit/compare/v2.0.1...v2.1.0
Published by markerikson 11 months ago
This major release :
createSlice
and createReducer
middleware
and enhancers
options of configureStore
to require callbackscombineSlices
method with support for lazy-loading slice reducerscreateSlice.reducers
, with optional support for defining thunks inside of createSlice
autoBatchEnhancer
to configureStore
by defaultThis release has breaking changes. (Note: v2.0.1 was released with a couple hotfixes for Reselect and Redux Thunk right as this was being finalized.)
This release is part of a wave of major versions of all the Redux packages: Redux Toolkit 2.0, Redux core 5.0, React-Redux 9.0, Reselect 5.0, and Redux Thunk 3.0.
For full details on all of the breaking changes and other significant changes to all of those packages, see the "Migrating to RTK 2.0 and Redux 5.0" migration guide in the Redux docs.
[!NOTE]
The Redux core, Reselect, and Redux Thunk packages are included as part of Redux Toolkit, and RTK users do not need to manually upgrade them - you'll get them as part of the upgrade to RTK 2.0. (If you're not using Redux Toolkit yet, please start migrating your existing legacy Redux code to use Redux Toolkit today!)
# RTK
npm install @reduxjs/toolkit
yarn add @reduxjs/toolkit
createSlice.extraReducers
and createReducer
removedRTK's createReducer
API was originally designed to accept a lookup table of action type strings to case reducers, like { "ADD_TODO": (state, action) => {} }
. We later added the "builder callback" form to allow more flexibility in adding "matchers" and a default handler, and did the same for createSlice.extraReducers
.
We have removed the "object" form for both createReducer
and createSlice.extraReducers
in RTK 2.0, as the builder callback form is effectively the same number of lines of code, and works much better with TypeScript.
As an example, this:
const todoAdded = createAction('todos/todoAdded')
createReducer(initialState, {
[todoAdded]: (state, action) => {},
})
createSlice({
name,
initialState,
reducers: {
/* case reducers here */
},
extraReducers: {
[todoAdded]: (state, action) => {},
},
})
should be migrated to:
createReducer(initialState, (builder) => {
builder.addCase(todoAdded, (state, action) => {})
})
createSlice({
name,
initialState,
reducers: {
/* case reducers here */
},
extraReducers: (builder) => {
builder.addCase(todoAdded, (state, action) => {})
},
})
To simplify upgrading codebases, we've published a set of codemods that will automatically transform the deprecated "object" syntax into the equivalent "builder" syntax.
The codemods package is available on NPM as @reduxjs/rtk-codemods
. More details are available here.
To run the codemods against your codebase, run npx @reduxjs/rtk-codemods <TRANSFORM NAME> path/of/files/ or/some**/*glob.js.
Examples:
npx @reduxjs/rtk-codemods createReducerBuilder ./src
npx @reduxjs/rtk-codemods createSliceBuilder ./packages/my-app/**/*.ts
We also recommend re-running Prettier on the codebase before committing the changes.
These codemods should work, but we would greatly appreciate feedback from more real-world codebases!
configureStore
Options ChangesconfigureStore.middleware
must be a callbackSince 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.
As a result, we've now made the middleware
only accept the callback form. 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 TS users, 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)
.
configureStore.enhancers
must be a callbackSimilarly to configureStore.middleware
, the enhancers
field must also be a callback, for the same reasons.
The callback will receive a getDefaultEnhancers
function that can be used to customise the batching enhancer that's now included by default.
For example:
const store = configureStore({
reducer,
enhancers: (getDefaultEnhancers) => {
return getDefaultEnhancers({
autoBatch: { type: 'tick' },
}).concat(myEnhancer)
},
})
It's important to note that the result of getDefaultEnhancers
will also contain the middleware enhancer created with any configured/default middleware. To help prevent mistakes, configureStore
will log an error to console if middleware was provided and the middleware enhancer wasn't included in the callback result.
const store = configureStore({
reducer,
enhancers: (getDefaultEnhancers) => {
return [myEnhancer] // we've lost the middleware here
// instead:
return getDefaultEnhancers().concat(myEnhancer)
},
})
Also, note that if you supply the enhancers
field, it must come after the middleware
field in order for TS inference to work properly.
getDefaultMiddleware
and getType
removedThe standalone version of getDefaultMiddleware
has been deprecated since v1.6.1, and has now been removed. Use the function passed to the middleware
callback instead, which has the correct types.
We have also removed the getType
export, which was used to extract a type string from action creators made with createAction
. Instead, use the static property actionCreator.type
.
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.
The biggest theme of the Redux v5 and RTK 2.0 releases is trying to get "true" ESM package publishing compatibility in place, while still supporting CJS in the published package.
The primary build artifact is now an ESM file, dist/redux-toolkit.modern.mjs
. Most build tools should pick this up. There's also a CJS artifact, and a second copy of the ESM file named redux-toolkit.legacy-esm.js
to support Webpack 4 (which does not recognize the exports
field in package.json
). Additionally, all of the build artifacts now live under ./dist/
in the published package.
We now publish modern JS syntax targeting ES2020, including optional chaining, object spread, and other modern syntax. If you need to
We're now building the package using https://github.com/egoist/tsup. We also now include sourcemaps for the ESM and CJS artifacts.
Redux has always shipped with UMD build artifacts. These are primarily meant for direct import as script tags, such as in a CodePen or a no-bundler build environment.
We've dropped those build artifacts from the published package, on the grounds that the use cases seem pretty rare today.
There's now a redux-toolkit.browser.mjs
file in the package that can be loaded from a CDN like Unpkg.
If you have strong use cases for us continuing to include UMD build artifacts, please let us know!
RTK now depends on Redux core 5.0, Reselect 5.0, and Redux Thunk 3.0. See the linked release notes for those libraries, as each of them has additional breaking changes. The "Migrating to RTK 2.0 and Redux 5.0" docs page also covers the combined changes in one page
RTK now also depends on Immer 10.0, which has several major improvements and updates:
We've also removed the prior call to automatically enable the Immer ES5 fallback mode any time RTK was loaded.
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.
reactHooksModule
custom hook configurationPreviously, custom versions of React Redux's hooks (useSelector
, useDispatch
, and useStore
) could be passed separately to reactHooksModule
, usually to enable using a different context to the default ReactReduxContext
.
In practicality, the react hooks module needs all three of these hooks to be provided, and it became an easy mistake to only pass useSelector
and useDispatch
, without useStore
.
The module has now moved all three of these under the same configuration key, and will check that all three are provided if the key is present.
// previously
const customCreateApi = buildCreateApi(
coreModule(),
reactHooksModule({
useDispatch: createDispatchHook(MyContext),
useSelector: createSelectorHook(MyContext),
useStore: createStoreHook(MyContext),
})
)
// now
const customCreateApi = buildCreateApi(
coreModule(),
reactHooksModule({
hooks: {
useDispatch: createDispatchHook(MyContext),
useSelector: createSelectorHook(MyContext),
useStore: createStoreHook(MyContext),
},
})
)
Several other options were previously marked as deprecated, and have been removed. We've also removed polyfills like the AbortController
polyfill.
configureStore
field order for middleware
mattersIf you are passing both the middleware
and enhancers
fields to configureStore
, the middleware
field must come first in order for internal TS inference to work properly.
Tuple
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: (getDefaultMiddleware) => 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.)
This same restriction applies to the enhancers
field.
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. If you use the EntityState<Data, Id>
type directly, you must supply both generic arguments!
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.
These features are new in Redux Toolkit 2.0, and help cover additional use cases that we've seen users ask for in the ecosystem.
combineSlices
API with slice reducer injection for code-splittingThe Redux core has always included combineReducers
, which takes an object full of "slice reducer" functions and generates a reducer that calls those slice reducers. RTK's createSlice
generates slice reducers + associated action creators, and we've taught the pattern of exporting individual action creators as named exports and the slice reducer as a default export. Meanwhile, we've never had official support for lazy-loading reducers, although we've had sample code for some "reducer injection" patterns in our docs.
This release includes a new combineSlices
API that is designed to enable lazy-loading of reducers at runtime. It accepts individual slices or an object full of slices as arguments, and automatically calls combineReducers
using the sliceObject.name
field as the key for each state field. The generated reducer function has an additional .inject()
method attached that can be used to dynamically inject additional slices at runtime. It also includes a .withLazyLoadedSlices()
method that can be used to generate TS types for reducers that will be added later. See #2776 for the original discussion around this idea.
For now, we are not building this into configureStore
, so you'll need to call const rootReducer = combineSlices(.....)
yourself and pass that to configureStore({reducer: rootReducer})
.
Basic usage: a mixture of slices and standalone reducers passed to combineSlices
const stringSlice = createSlice({
name: 'string',
initialState: '',
reducers: {},
})
const numberSlice = createSlice({
name: 'number',
initialState: 0,
reducers: {},
})
const booleanReducer = createReducer(false, () => {})
const api = createApi(/* */)
const combinedReducer = combineSlices(
stringSlice,
{
num: numberSlice.reducer,
boolean: booleanReducer,
},
api
)
expect(combinedReducer(undefined, dummyAction())).toEqual({
string: stringSlice.getInitialState(),
num: numberSlice.getInitialState(),
boolean: booleanReducer.getInitialState(),
api: api.reducer.getInitialState(),
})
Basic slice reducer injection
// Create a reducer with a TS type that knows `numberSlice` will be injected
const combinedReducer =
combineSlices(stringSlice).withLazyLoadedSlices<
WithSlice<typeof numberSlice>
>()
// `state.number` doesn't exist initially
expect(combinedReducer(undefined, dummyAction()).number).toBe(undefined)
// Create a version of the reducer with `numberSlice` injected (mainly useful for types)
const injectedReducer = combinedReducer.inject(numberSlice)
// `state.number` now exists, and injectedReducer's type no longer marks it as optional
expect(injectedReducer(undefined, dummyAction()).number).toBe(
numberSlice.getInitialState()
)
// original reducer has also been changed (type is still optional)
expect(combinedReducer(undefined, dummyAction()).number).toBe(
numberSlice.getInitialState()
)
selectors
field in createSlice
The existing createSlice
API now has support for defining selectors
directly as part of the slice. By default, these will be generated with the assumption that the slice is mounted in the root state using slice.name
as the field, such as name: "todos"
-> rootState.todos
. Additionally, there's now a slice.selectSlice
method that does that default root state lookup.
You can call sliceObject.getSelectors(selectSliceState)
to generate the selectors with an alternate location, similar to how entityAdapter.getSelectors()
works.
const slice = createSlice({
name: 'counter',
initialState: 42,
reducers: {},
selectors: {
selectSlice: (state) => state,
selectMultiple: (state, multiplier: number) => state * multiplier,
},
})
// Basic usage
const testState = {
[slice.name]: slice.getInitialState(),
}
const { selectSlice, selectMultiple } = slice.selectors
expect(selectSlice(testState)).toBe(slice.getInitialState())
expect(selectMultiple(testState, 2)).toBe(slice.getInitialState() * 2)
// Usage with the slice reducer mounted under a different key
const customState = {
number: slice.getInitialState(),
}
const { selectSlice, selectMultiple } = slice.getSelectors(
(state: typeof customState) => state.number
)
expect(selectSlice(customState)).toBe(slice.getInitialState())
expect(selectMultiple(customState, 2)).toBe(slice.getInitialState() * 2)
createSlice.reducers
callback syntax and thunk supportOne 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:
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.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:
createSlice
, you specifically need to set up a custom version of createSlice
that has access to createAsyncThunk
.createSlice.reducers
, by using a "creator callback" syntax for the reducers
field that is similar to the build
callback syntax in RTK Query's createApi
(using typed functions to create fields in an object). Doing this does look a bit different than the existing "object" syntax for the reducers
field, but is still fairly similar.createSlice
, but you cannot customize the state
or dispatch
types. If those are needed, you can manually do an as
cast, like getState() as RootState
.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, setting up a custom createSlice
allows you to opt into createAsyncThunk
being included in your bundle size (though it may already be included if used directly or as part of RTK Query - in either of these cases there's no additional bundle size).
Here's what the new callback syntax looks like:
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
},
}
),
}),
})
// `addTodo` and `deleteTodo` are normal action creators.
// `fetchTodo` is the async thunk
export const { addTodo, deleteTodo, fetchTodo } = todosSlice.actions
Using the new callback syntax is entirely optional (the object syntax is still standard), but an existing slice would need to be converted before it can take advantage of the new capabilities this syntax provides. To make this easier, a codemod is provided.
npx @reduxjs/rtk-codemods createSliceReducerBuilder ./src/features/todos/slice.ts
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 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)
configureStore
adds autoBatchEnhancer
by defaultIn 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.
entityAdapter.getSelectors
accepts a createSelector
functionentityAdapter.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.
We now have a docs page that covers how to set up Redux properly with Next.js. We've seen a lot of questions around using Redux, Next, and the App Router together, and this guide should help provide advice.
(At this time, the Next.js with-redux
example is still showing outdated patterns - we're going to file a PR shortly to update that to match our docs guide.)
v2.0-integration
by @markerikson in https://github.com/reduxjs/redux-toolkit/pull/3253
arethetypeswrong
automated CLI check by @markerikson in https://github.com/reduxjs/redux-toolkit/pull/3294
attw
CLI option to treat problems as non-errors by @markerikson in https://github.com/reduxjs/redux-toolkit/pull/3316
tsup
by @markerikson in https://github.com/reduxjs/redux-toolkit/pull/3362
responseHandler
being used in fetchBaseQuery
by @praxxis in https://github.com/reduxjs/redux-toolkit/pull/3137
resetApiState
by @phryneas in https://github.com/reduxjs/redux-toolkit/pull/3333
subscriptionUpdated
as autobatched by @markerikson in https://github.com/reduxjs/redux-toolkit/pull/3364
createSelector
instance to adapter.getSelectors by @EskiMojo14 in https://github.com/reduxjs/redux-toolkit/pull/3481
listenerApi.throwIfCancelled()
by @markerikson in https://github.com/reduxjs/redux-toolkit/pull/3802
autotrackMemoize
by @markerikson in https://github.com/reduxjs/redux-toolkit/pull/3831
createDraftSafeSelector
. by @aryaemami59 in https://github.com/reduxjs/redux-toolkit/pull/3722
Full Changelog: https://github.com/reduxjs/redux-toolkit/compare/v1.9.3...v2.0.0
Published by markerikson 11 months ago
This release candidate updates to the latest Reselect 5.0 RC to pick up the rename of defaultMemoize
to lruMemoize
.
Note that we hope to release Redux Toolkit 2.0, Redux core 5.0, and React-Redux 9.0 by this weekend!
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@next
The previous v2.0.0-rc.2
release picked up Reselect's dev mode checks for result functions that just return their input, like x => x
. Turns out that some of RTK Query's internal selector usage did that in some cases :) That resulted in a ton of warnings being printed. We've updated our internals to fix that.
The Reselect defaultMemoize
function has now been renamed to lruMemoize
, since it's no longer the default. See the Reselect v5.0.0-rc.1
release notes for more details.
lruMemoize
rename by @markerikson in https://github.com/reduxjs/redux-toolkit/pull/3933
Full Changelog: https://github.com/reduxjs/redux-toolkit/compare/v2.0.0-rc.2...v2.0.0-rc.3
Published by markerikson 11 months ago
This release candidate updates to the latest Reselect 5.0 RC to pick up the change to use weakMapMemoize
as the default inside createSelector
.
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@next
Reselect v5.0.0-rc.0 makes the breaking change to use weakMapMemoize
as the default memoization implementation for createSelector
. This memoizer has an effectively infinite cache size, which should cut down on the number of recalculations in a typical app, and help improve performance overall. This is a breaking change, but one that should be invisible to most users.
It also adds a new dev-mode check for result functions that look like x => x
, which is almost always a mistake.
See the Reselect v5.0.0-rc.0 release notes for more details.
weakMapMemoize
change by @markerikson in https://github.com/reduxjs/redux-toolkit/pull/3928
Full Changelog: https://github.com/reduxjs/redux-toolkit/compare/v2.0.0-rc.1...v2.0.0-rc.2
Published by markerikson 11 months ago
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@next
isAction
PredicateWe 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.
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!
v2.0-integration
by @markerikson in https://github.com/reduxjs/redux-toolkit/pull/3903
Full Changelog: https://github.com/reduxjs/redux-toolkit/compare/v2.0.0-rc.0...v2.0.0-rc.1
Published by markerikson 11 months ago
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@next
createSlice
changesIn 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
},
}
),
}),
})
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.
createDraftSafeSelector
. by @aryaemami59 in https://github.com/reduxjs/redux-toolkit/pull/3722
Full Changelog: https://github.com/reduxjs/redux-toolkit/compare/v2.0.0-beta.4...v2.0.0-rc.0
Published by markerikson 12 months ago
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@beta
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:
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.
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.
autotrackMemoize
by @markerikson in https://github.com/reduxjs/redux-toolkit/pull/3831
Full Changelog: https://github.com/reduxjs/redux-toolkit/compare/v2.0.0-beta.3...v2.0.0-beta.4
Published by markerikson about 1 year ago
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@beta
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:
configureStore.middleware
Option Must Be A CallbackSince 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)
.
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).
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.
Full Changelog: https://github.com/reduxjs/redux-toolkit/compare/v2.0.0-beta.2...v2.0.0-beta.3
Published by markerikson about 1 year ago
This bugfix release rewrites the RTKQ hook TS types to significantly improve 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.
Full Changelog: https://github.com/reduxjs/redux-toolkit/compare/v1.9.6...v1.9.7
Published by markerikson about 1 year ago
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@beta
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:
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.
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
.
1.9.6
into v2.0-integration
by @markerikson in https://github.com/reduxjs/redux-toolkit/pull/3743
Full Changelog: https://github.com/reduxjs/redux-toolkit/compare/v2.0.0-beta.1...v2.0.0-beta.2
Published by markerikson about 1 year ago
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.
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.
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.
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.
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
.
Full Changelog: https://github.com/reduxjs/redux-toolkit/compare/v1.9.5...v1.9.6
Published by markerikson about 1 year ago
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@beta
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:
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.
We removed the AbortController
polyfill from createAsyncThunk
, saving some bytes.
We've updated deps to [email protected]
and [email protected]
.
Full Changelog: https://github.com/reduxjs/redux-toolkit/compare/v2.0.0-beta.0...v2.0.0-beta.1
Published by markerikson over 1 year ago
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@next
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:
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.
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.
UnknownAction
TypeThe 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>
}
Summarizing the changes from earlier alphas:
combineSlices
API with built-in support for slice reducer injection for code-splittingselectors
field in createSlice
createSlice.reducers
, which allows defining thunks inside createSlice
configureStore
adds autoBatchEnhancer
by defaultautotrack
and weakmap
memoizers with different tradeoffscreateReducer
and createSlice.extraReducers
has been removed5.0-beta
actionCreator.toString()
override removed (although we're reconsidering this)getDefaultMiddleware
removedcreateSelector
instance to adapter.getSelectors by @EskiMojo14 in https://github.com/reduxjs/redux-toolkit/pull/3481
Full Changelog: https://github.com/reduxjs/redux-toolkit/compare/v2.0.0-alpha.6...v2.0.0-beta.0
Published by markerikson over 1 year ago
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@alpha
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 some of the new features here:
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:
createSlice.reducers
, by using a "creator callback" syntax for the reducers
field that is similar to the build
callback syntax in RTK Query's createApi
(using typed functions to create fields in an object). Doing this does look a bit different than the existing "object" syntax for the reducers
field, but is still fairly similar.createSlice
, but you cannot customize the state
or dispatch
types. If those are needed, you can manually do an as
cast, like getState() as RootState
.createSlice
does now always depend on createAsyncThunk
, so the createAsyncThunk
implementation 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
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)
autoBatchEnhancer
By DefaultIn 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),
})
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.middleware
field that has correct types attached.
Finally, we've removed all other fields or type exports that were marked as deprecated in 1.9.x.
We've updated Reselect with the same ESM/CJS package formatting updates as the rest of the Redux libraries.
Reselect v5 alpha now includes a pair of new memoizers: autotrackMemoize
, which uses signal-style field tracking, and weakmapMemoize
, which has an effectively infinite cache size thanks to use of WeakMap
s for tracking arguments.
We'd appreciate it if users would try out the new memoizers in their apps and give us feedback on their usefulness and any problems or suggestions!
You can use these by creating a customized version of createSelector
, and RTK now exports createSelectorCreator
and all three memoizers:
import { createSelectorCreator, autotrackMemoize} from "@reduxjs/toolkit"
const createSelectorAutotrack = createSelectorCreator(autotrackMemoize);
See the Reselect v5 alpha release notes for details on the tradeoffs with each memoizer:
Reselect also now automatically calls each selector twice on first execution in development builds, in order to detect cases where input selectors accidentally return new references too often (which would cause memoization to fail):
This can be configured on a per-selector basis. There's also a global setInputStabilityCheckEnabled()
override method that is exported from the reselect
package, but is not re-exported from RTK, as we think the check-once behavior is the right default. If you really want to override that globally, add reselect
as an explicit dependency and import the override from there.
We've updated to Redux core v2.0-alpha.6, which enforces that action.type
must be a string. In practice this shouldn't affect any of our users - action type strings are mostly an implementation detail now, and RTK uses strings for all actions.
We've updated all the Redux libraries to requires TS 4.7 as a minimum version. Some of our new types require this anyway, and it also simplifies the maintenance of our type definitions.
Full Changelog: https://github.com/reduxjs/redux-toolkit/compare/v2.0.0-alpha.5...v2.0.0-alpha.6
Published by markerikson over 1 year ago
This is an alpha release for Redux Toolkit 2.0. This release adds a new combineSlices
API for reducer injection, has many changes to our build setup and published package contents, updates the redux
dep to the latest alpha, updates the immer
dep to 10.0 final, includes the latest changes from 1.9.x, and has breaking changes.
combineSlices
APIThe Redux core has always included combineReducers
, which takes an object full of "slice reducer" functions and generates a reducer that calls those slice reducers. RTK's createSlice
generates slice reducers + associated action creators, and we've taught the pattern of exporting individual action creators as named exports and the slice reducer as a default export. Meanwhile, we've never had official support for lazy-loading reducers, although we've had sample code for some "reducer injection" patterns in our docs.
This release includes a new combineSlices
API that is designed to enable lazy-loading of reducers at runtime. It accepts individual slices or an object full of slices as arguments, and automatically calls combineReducers
using the sliceObject.name
field as the key for each state field. The generated reducer function has an additional .inject()
method attached that can be used to dynamically inject additional slices at runtime. It also includes a .withLazyLoadedSlices()
method that can be used to generate TS types for reducers that will be added later. See https://github.com/reduxjs/redux-toolkit/issues/2776 for the original discussion around this idea.
For now, we are not building this into configureStore
, so you'll need to call const rootReducer = combineSlices(.....)
yourself and pass that to configureStore({reducer: rootReducer})
.
We don't have documentation added for these features yet, but here's example usages from the combineSlices
PR tests:
combineSlices
const stringSlice = createSlice({
name: 'string',
initialState: '',
reducers: {},
})
const numberSlice = createSlice({
name: 'number',
initialState: 0,
reducers: {},
})
const booleanReducer = createReducer(false, () => {})
const api = createApi(/* */)
const combinedReducer = combineSlices(
stringSlice,
{
num: numberSlice.reducer,
boolean: booleanReducer,
},
api
)
expect(combinedReducer(undefined, dummyAction())).toEqual({
string: stringSlice.getInitialState(),
num: numberSlice.getInitialState(),
boolean: booleanReducer.getInitialState(),
api: api.reducer.getInitialState(),
})
// Create a reducer with a TS type that knows `numberSlice` will be injected
const combinedReducer =
combineSlices(stringSlice).withLazyLoadedSlices<
WithSlice<typeof numberSlice>
>()
// `state.number` doesn't exist initially
expect(combinedReducer(undefined, dummyAction()).number).toBe(undefined)
// Create a new reducer with `numberSlice` injected
const injectedReducer = combinedReducer.inject(numberSlice)
// `state.number` now exists
expect(injectedReducer(undefined, dummyAction()).number).toBe(
numberSlice.getInitialState()
)
createSlice
The existing createSlice
API now has support for defining selectors
directly as part of the slice. By default, these will be generated with the assumption that the slice is mounted in the root state using slice.name
as the field, such as name: "todos"
-> rootState.todos
. You can call sliceObject.getSelectors(selectSliceState)
to generate the selectors with an alternate location, similar to how entityAdapter.getSelectors()
works.
const slice = createSlice({
name: 'counter',
initialState: 42,
reducers: {},
selectors: {
selectSlice: (state) => state,
selectMultiple: (state, multiplier: number) => state * multiplier,
},
})
// Basic usage
const testState = {
[slice.name]: slice.getInitialState(),
}
const { selectSlice, selectMultiple } = slice.selectors
expect(selectSlice(testState)).toBe(slice.getInitialState())
expect(selectMultiple(testState, 2)).toBe(slice.getInitialState() * 2)
// Usage with the slice reducer mounted under a different key
const customState = {
number: slice.getInitialState(),
}
const { selectSlice, selectMultiple } = slice.getSelectors(
(state: typeof customState) => state.number
)
expect(selectSlice(customState)).toBe(slice.getInitialState())
expect(selectMultiple(customState, 2)).toBe(slice.getInitialState() * 2)
We've switched our build setup to use tsup
, an ESBuild-powered build framework. This release should have identical build artifacts to 2.0.0-alpha.4
, but let us know if there are any issues!
Immer 10.0 is now final, and has several major improvements and updates:
We've updated RTK to depend on the final Immer 10.0 release .
We've updated RTK to use the latest Redux 5.0-alpha.5
release, which tweaks the Reducer
type, drops the internal $CombinedState
type, and updates middleware types to default to unknown
for actions.
For RTK, we've improved type inference for store enhancers, especially those that add additional fields to the state or store.
tsup
by @markerikson in https://github.com/reduxjs/redux-toolkit/pull/3362
responseHandler
being used in fetchBaseQuery
by @praxxis in https://github.com/reduxjs/redux-toolkit/pull/3137
resetApiState
by @phryneas in https://github.com/reduxjs/redux-toolkit/pull/3333
subscriptionUpdated
as autobatched by @markerikson in https://github.com/reduxjs/redux-toolkit/pull/3364
Full Changelog: https://github.com/reduxjs/redux-toolkit/compare/v2.0.0-alpha.4...v2.0.0-alpha.5