fix(deps): update dependency @reduxjs/toolkit to ^1.9.1 #3346
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR contains the following updates:
^1.8.5
->^1.9.1
Release Notes
reduxjs/redux-toolkit
v1.9.1
Compare Source
This bugfix release fixes assorted issues that were reported with RTK 1.9.0, and adds a few additional requested tweaks and improvements.
Changelog
Fixes
The
createAsyncThunk.withTypes
function was fully broken (it type-checked correctly, but pointed to the wrong function due to a name shadowing issue). That now works correctly.The
maxRetries
option for RTKQ was inadvertently filtering out0
values, and those are now accepted.fulfillWithValue
had incorrect types that made it appear as if the data was nested an additional level deeper. The types are now correct.The
ActionCreatorWithoutPayload
type was tweaked to force an error when an action creator is accidentally called with an argument, which happens in cases likeonClick={todoAdded}
. This avoids accidentally passing values like React event objects as the payload.Timer handling for
batchActions
andautoBatchEnhancer
now works in more JS runtime environments.Other Changes
The
TagDescription
type is now exported from RTKQ.API endpoints now have a
.name
field containing the endpoint name, such as"getPokemon"
.Calling
promise.abort()
on acreateAsyncThunk
promise before an asynccondition
resolves will now be treated as if thecondition
itself returnedfalse
, bailing out and not dispatching anything.The
merge
option now receives a third argument containing{arg, baseQueryMeta, fulfilledTimeStamp, requestId}
, in case that info is useful in deciding how to merge.The
@reduxjs/rtk-codemods
package has been updated to fix cases where thecreateSliceBuilder
codemod didn't preserve fields with function variable arguments, like[todoAdded]: adapter.addOne
. That package has been updated to v0.0.3.What's Changed
Full Changelog: reduxjs/redux-toolkit@v1.9.0...v1.9.1
v1.9.0
Compare Source
This feature release adds several new options for RTK Query's
createApi
andfetchBaseQuery
APIs, adds a newupsertQueryData
util, rewrites RTKQ's internals for improved performance, adds a newautoBatchEnhancer
, deprecates the "object" syntax forcreateReducer
andcreateSlice.extraReducers
, deprecates and removes broken utils for getting running query promises, improves TS inference, exports additional types, and fixes a number of reported issues.We plan to start work on RTK 2.0 in the next few weeks. RTK 2.0 will focus on dropping legacy build compatibility and deprecated APIs, with some potential new features. See the linked discussion thread and give us feedback on ideas!
Deprecations and Removals
Object Argument for
createReducer
andcreateSlice.extraReducers
RTK'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 forcreateSlice.extraReducers
.We intend to remove the "object" form for both
createReducer
andcreateSlice.extraReducers
in RTK 2.0. The builder callback form is effectively the same number of lines of code, and works much better with TypeScript.Starting with this release, RTK will print a one-time runtime warning for both
createReducer
andcreateSlice.extraReducers
if you pass in an object argument.As an example, this:
should be migrated to:
Codemods for Deprecated Object Reducer Syntax
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
. It currently contains two codemods:createReducerBuilder
andcreateSliceBuilder
.To run the codemods against your codebase, run
npx @​reduxjs/rtk-codemods <TRANSFORM NAME> path/of/files/ or/some**/*glob.js
.Examples:
We also recommend re-running Prettier on the codebase before committing the changes.
These codemods should work, but we would greatly appreciate testing and feedback on more real-world codebases!
Object reducer codemod before/after examples
Before:After:
getRunningOperationPromises
Deprecation and ReplacementIn
v1.7.0
, we added anapi.util.getRunningOperationPromises()
method for use with SSR scenarios, as well as a singulargetRunningOperationPromise()
method intended for possible use with React Suspense.Unfortunately, in #2477 we realized that both those methods have a fatal flaw - they do not work with multiple stores in SSR.
As of this release, we are immediately marking
getRunningOperationPromises()
as deprecated and discouraging its use before we remove it completely in RTK 2.0! It will now throw both runtime and compile errors in development to enforce moving away from using it. However, we are leaving its existing behavior in production builds to avoid actual breakage.The
getRunningOperationPromise()
util was experimental, and as far as we can tell not actually being used by anyone, so we are removinggetRunningOperationPromise
completely in this release.As replacements, RTKQ now includes four new thunks attached to
api.util
:getRunningQueryThunk(endpointName, queryArgs)
getRunningMutationThunk(endpointName, fixedCacheKeyOrRequestId)
getRunningQueriesThunk()
getRunningMutationsThunk()
Usages would typically change like this:
Changelog
New RTK Query
createApi
OptionscreateApi
endpoints now have several additional options that can be passed in, some of which are intended to work together.merge
OptionRTKQ was built around the assumption that the server is the source of truth, and every refetch replaces the cached data on the client. There are use cases when it would be useful to merge an incoming response into the existing cached data instead, such as pagination or APIs that return varying results over time.
Query endpoints can now accept a
merge(cachedData, responseData)
callback that lets you do Immer-powered "mutations" to update the existing cached data instead of replacing it entirely.Since RTKQ assumes that each response per key should replace the existing cache entry by default, the
merge
option is expected to be used with theserializeQueryArgs
andforceRefetch
options, as described below.serializeQueryArgs
OptionRTK Query always serializes the cache key value, and uses the string as the actual key for storing the cache entry. The default serialization is the name of the endpoint, plus either the primitive value or a stable-serialized object. An example might be
state.api.queries['getPokemon("pikachu")']
.RTKQ already supported customization of this serialization behavior at the
createApi
level. Now, each endpoint can specify its ownserializeQueryArgs
method.The per-endpoint
serializeQueryArgs
may return either a string, an object, a number, or a boolean. If it's a string, that value will be used as-is. Otherwise, the return value will be run through the default serialization logic. This simplifies the common case of stripping out a couple unwanted object fields from the cache key.This option serves two main purposes: leaving out values that are passed in to an endpoint but not really part of the "key" conceptually (like a socket or client instance), and altering cache key behavior to use a single entry for the endpoint (such as in an infinite loading / pagination scenario).
Also, the
defaultSerializeQueryArgs
util is now exported.forceRefresh
optionSometimes you may want to force a refetch, even though RTKQ thinks that the serialized query args haven't changed and there's already a fulfilled cache entry.
This can be used to force RTKQ to actually refetch. One expected use case is an "infinite pagination" scenario where there is one cache entry for the endpoint, different page numbers are given as query args, and the incoming responses are merged into the existing cache entry:
transformErrorResponse
OptionSimilar to
transformResponse
, endpoints can now specify atransformErrorResponse
option as well.upsertQueryData
UtilRTKQ already has an
updateQueryData
util to synchronously modify the contents of an existing cache entry, but there was no way to create a new cache entry and its metadata programmatically.This release adds a new
api.util.upsertQueryData
API that allows creating a cache entry + its data programmatically. As with the other util methods, this is a thunk that should be dispatched, and you should pass in the exact cache key arg and complete data value you want to insert:The dispatch acts like all other RTKQ requests, so the process is async, and the thunk returns a promise that resolves when the upsert is complete.
RTK Query Performance Improvements
We've significantly rewritten RTK Query's internal implementation to improve performance, especially in cases where many components with query hooks mount at the same time. The middleware has been "flattened" and runs fewer internal checks against each action, subscription updates are grouped together, and some unnecessary memoized selectors have been removed. One consequence is that forgetting to add the RTKQ middleware now throws an error instead of logging a warning.
Overall, RTK Query processing time should be noticeably faster than it was in 1.8.
RTK Query also can take advantage of the new "auto-batch enhancer" (described below) for some additional perf optimization, and we recommend adding that to your Redux store configuration.
fetchBaseQuery
OptionsfetchBaseQuery
has several new options for processing requests:You can now specify a
timeout
option for both individual endpoints andfetchBaseQuery
. If provided, requests that take longer than this value will automatically abort.fetchBaseQuery
now supports passing theresponseHandler
andvalidateStatus
options directly tofetchBaseQuery
itself, in addition to accepting it as part of specific endpoints. If provided, these options will be applied as defaults to all requests for that API, which simplifies using them on many endpoints. Providing them for endpoints overrides the global option.You can now specify a
jsonContentType
string that will be used to set thecontent-type
header for a request with a jsonifiable body that does not have an explicitcontent-type
header. Defaults to"application/json"
.You can now specify a
isJsonContentType
callback that checks to see if the request body or response body should be stringified. The default looks for values like"application/json"
and"application/vnd.api+json"
. You can also now specifyresponseHandler: 'content-type'
to have RTKQ automatically check to see whether a response should be treated as text or JSON.The
prepareHeaders
method can now return void and does not have toreturn headers
.Other RTK Query Changes
The
refetch()
methods now return a promise that can be awaited.Query endpoints can now accept a
retryCondition
callback as an alternative tomaxRetries
. If you provideretryCondition
, it will be called to determine if RTKQ should retry a failed request again.New Auto-Batching Store Enhancer
There are several different ways to "batch actions" with Redux stores, ranging from reducers to debounced subscriber notifications.
RTK now includes a new
autoBatchEnhancer()
store enhancer that uses a variation on the "debounced notification" approach, inspired by React's technique of batching renders and determining if an update is low-priority or high-priority.The enhancer looks for any actions tagged with an
action.meta[SHOULD_AUTOBATCH] = true
flag, and delays notifying subscribers until a queued callback runs. This means that if multiple "auto-batched" actions are dispatched in a row, there will be only one subscriber notification. However, if any "normal-priority" action without that flag are dispatched before the queued callback runs, the enhancer will notify subscribers immediately instead and ignore the callback.This allows Redux users to selectively tag certain actions for effective batching behavior, making this purely opt-in on a per-action basis, while retaining normal notification behavior for all other actions.
The enhancer defaults to using
requestAnimationFrame
, but can also be configured to usequeueMicrotask
to run at the end of an event loop tick,setTimeout
, or a user-provided callback.RTK Query's internals have been updated to mark several key actions as batchable. While the enhancer is purely opt-in, benchmarks indicate that it can help speed up UI performance with RTK Query, especially when rendering many components with query hooks. We recommend adding this enhancer to your store setup if you're using RTK Query:
Additionally, there's a
prepareAutoBatched
util that can be used to help add theSHOULD_AUTOBATCH
flag to actions, designed for use withcreateSlice
:TypeScript Improvements
RTK 1.9 now requires TS 4.2 or greater, and supports through TS 4.9.
The action type strings generated by
createAction
are now full TS template literals when possible.There's now a
createAsyncThunk.withTypes()
method that creates a "pre-typed" version ofcreateAsyncThunk
with types like{state, dispatch, extra}
baked in. This can be used to simplify customizingcreateAsyncThunk
with the right types once during app setup.RTK Query now exports TS types for "pre-typed hook results", for cases when you want to wrap the query/mutation hooks in your own code. Additionally, RTKQ also exports
BaseQueryApi
and exposes TS-only types for endpoint definitions.configureStore
now correctly infers changes to the store shape from any store enhancers, such as adding actual extra fields tostore
.RTK now exports additional types from
redux-thunk
.Bug Fixes
Manually initiated RTKQ promises should resolve correctly.
Previous API tags are removed before adding new ones, instead of accidentally merging them together.
invalidateTags
works correctly when dealing with persisted query state.What's Changed
isJsonContentType
predicate tofetchBaseQuery
by @msutkowski in https://github.com/reduxjs/redux-toolkit/pull/2331jsonContentType
tofetchBaseQuery
options by @msutkowski in https://github.com/reduxjs/redux-toolkit/pull/2403StoreEnhancers
by @fostyfost in https://github.com/reduxjs/redux-toolkit/pull/2550refetch
by @phryneas in https://github.com/reduxjs/redux-toolkit/pull/2212upsertQueryData
race situations by @phryneas in https://github.com/reduxjs/redux-toolkit/pull/2646error
. by @phryneas in https://github.com/reduxjs/redux-toolkit/pull/2743dispatchQueued
variable after flushing by @phryneas in https://github.com/reduxjs/redux-toolkit/pull/2757forceRefetch
toQueryExtraOptions
by @schadenn in https://github.com/reduxjs/redux-toolkit/pull/2663prepareHeaders
does not need to returnheaders
any more by @phryneas in https://github.com/reduxjs/redux-toolkit/pull/2775codemods-cli
and rewrite "object reducer" codemods by @markerikson in https://github.com/reduxjs/redux-toolkit/pull/2768skipToken
behaviour inuseQueryState
by @phryneas in https://github.com/reduxjs/redux-toolkit/pull/2779fetchBaseQuery
: allowheaders
option by @phryneas in https://github.com/reduxjs/redux-toolkit/pull/2778getRunningOperationPromise(s)
withgetRunning(Query|Queries|Mutation|Mutations)Thunk
by @phryneas in https://github.com/reduxjs/redux-toolkit/pull/2481responseHandler
andvalidateStatus
configuration by @phryneas in https://github.com/reduxjs/redux-toolkit/pull/2823Full Changelog: reduxjs/redux-toolkit@v1.8.6...v1.9.0
v1.8.6
Compare Source
This bugfix release fixes a couple of issues with RTKQ endpoint tags not invalidating correctly, and tweaks the
dispatch
type inference to handle more variations of arrays.What's Changed
dispatch
type inference to correctly handle read-only middleware arrays by @dokmic in https://github.com/reduxjs/redux-toolkit/pull/2629Full Changelog: reduxjs/redux-toolkit@v1.8.5...v1.8.6
Configuration
📅 Schedule: Branch creation - At any time (no schedule defined), Automerge - At any time (no schedule defined).
🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.
♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.
🔕 Ignore: Close this PR and you won't be reminded about this update again.
This PR has been generated by Mend Renovate. View repository job log here.