fix(deps): update dependency @reduxjs/toolkit to v2.9.0 #722
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.
Coming soon: The Renovate bot (GitHub App) will be renamed to Mend. PRs from Renovate will soon appear from 'Mend'. Learn more here.
This PR contains the following updates:
2.8.2->2.9.0Release Notes
reduxjs/redux-toolkit (@reduxjs/toolkit)
v2.9.0Compare Source
This feature release rewrites RTK Query's internal subscription and polling systems and the
useStableQueryArgshook for better perf, adds automaticAbortSignalhandling to requests still in progress when a cache entry is removed, fixes a bug with thetransformResponseoption for queries, adds a newbuilder.addAsyncThunkmethod, and fixes assorted other issues.Changelog
RTK Query Performance Improvements
We had reports that RTK Query could get very slow when there were thousands of subscriptions to the same cache entry. After investigation, we found that the internal polling logic was attempting to recalculate the minimum polling time after every new subscription was added. This was highly inefficient, as most subscriptions don't change polling settings, and it required repeated O(n) iteration over the growing list of subscriptions. We've rewritten that logic to debounce the update check and ensure a max of one polling value update per tick for the entire API instance.
Related, while working on the request abort changes, testing showed that use of plain
Records to hold subscription data was inefficient because we have to iterate keys to check size. We've rewritten the subscription handling internals to useMaps instead, as well as restructuring some additional checks around in-flight requests.These two improvements drastically improved runtime perf for the thousands-of-subscriptions-one-cache-entry repro, eliminating RTK methods as visible hotspots in the perf profiles. It likely also improves perf for general usage as well.
We've also changed the implementation of our internal
useStableQueryArgshook to avoid callingserializeQueryArgson its value, which can avoid potential perf issues when a query takes a very large object as its cache key.Abort Signal Handling on Cleanup
We've had numerous requests over time for various forms of "abort in-progress requests when the data is no longer needed / params change / component unmounts / some expensive request is taking too long". This is a complex topic with multiple potential use cases, and our standard answer has been that we don't want to abort those requests - after all, cache entries default to staying in memory for 1 minute after the last subscription is removed, so RTKQ's cache can still be updated when the request completes. That also means that it doesn't make sense to abort a request "on unmount".
However, it does then make sense to abort an in-progress request if the cache entry itself is removed. Given that, we've updated our cache handling to automatically call the existing
resPromise.abort()method in that case, triggering theAbortSignalattached to thebaseQuery. The handling at that point depends on your app -fetchBaseQueryshould handle that, a custombaseQueryorqueryFnwould need to listen to theAbortSignal.We do have an open issue asking for further discussions of potential abort / cancelation use cases and would appreciate further feedback.
New Options
The builder callback used in
createReducerandcreateSlice.extraReducersnow hasbuilder.addAsyncThunkavailable, which allows handling specific actions from a thunk in the same way that you could define a thunk insidecreateSlice.reducers:createApiand individual endpoint definitions now accept askipSchemaValidationoption with an array of schema types to skip, ortrueto skip validation entirely (in case you want to use a schema for its types, but the actual validation is expensive).Bug Fixes
The infinite query implementation accidentally changed the query internals to always run
transformResponseif provided, including if you were usingupsertQueryData(), which then broke. It's been fixed to only run on an actual query request.The internal changes to the structure of the
state.api.providedstructure broke our handling ofextractRehydrationInfo- we've updated that to handle the changed structure.The infinite query status fields like
hasNextPageare now a looser type ofbooleaninitially, rather than strictlyfalse.TS Types
We now export Immer's
WritableDrafttype to fix another non-portable types issue.We've added an
api.endpoints.myEndpoint.types.RawResultTypetypes-only field to match the other available fields.What's Changed
transformResponsewhen aqueryis used by @markerikson in #5049Full Changelog: reduxjs/redux-toolkit@v2.8.2...v2.9.0
Configuration
📅 Schedule: Branch creation - Between 12:00 AM and 03:59 AM, only on Monday ( * 0-3 * * 1 ) in timezone America/New_York, Automerge - At any time (no schedule defined).
🚦 Automerge: Enabled.
♻ Rebasing: Whenever PR is behind base branch, or you tick the rebase/retry checkbox.
🔕 Ignore: Close this PR and you won't be reminded about this update again.
This PR was generated by Mend Renovate. View the repository job log.