[Snyk] Upgrade @reduxjs/toolkit from 2.3.0 to 2.4.0 #434
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.
Snyk has created this PR to upgrade @reduxjs/toolkit from 2.3.0 to 2.4.0.
ℹ️ Keep your dependencies up-to-date. This makes it easier to fix existing vulnerabilities and to more quickly identify and fix newly disclosed vulnerabilities when they affect your project.
The recommended version is 1 version ahead of your current version.
The recommended version was released 21 days ago.
Release notes
Package name: @reduxjs/toolkit
This feature release includes multiple tweaks and fixes to RTK Query functionality, additional exported TS types, and drops support for TS versions earlier than 5.0.
Changelog
RTK Query Improvements
Lazy query hooks can now be reset.
retry.fail
now acceptsmeta
as a second argument.Tag invalidation arrays now ignore nullish values.
We did some small internal refactoring around Maps and default values that shrank bundle size slightly.
Bugfixes
Passing
skipToken
to a query hook now bails out before running any other logic, which fixes cases whereserializeQueryArgs
previously threw an error because there were no args to process.The
autoBatchEnhancer
now readswindow.requestAnimationFrame
later, which it to work properly with Jest fake timers.We fixed cases where the hook result
isSuccess
flag would briefly flicker tofalse
when switched to a different cache entry that was uninitialized, and would briefly flicker totrue
when refetching a query that previously errored.The listener middleware previously had inconsistent logic checks for comparing against existing listener entries (effect + type, vs effect only). It now always checks both effect + type.
Additional TS Types
We now export
Typed[Query|Mutation]OnQueryStarted
helpers to let you defineonQueryStarted
callbacks outside ofcreateApi
if desired.We also now export a
CreateAsyncThunkFunction
type that can be used to type userland wrappers aroundcreateAsyncThunk
.TS Support Matrix Updates
We've historically tried to maintain TS backwards compatibility as long as possible, and made occasional updates to our TS support matrix in minor versions over time. As of RTK 2.3.0, we officially supported back through TS 4.7.
As of this release, we're tweaking that support policy to match the policy used by DefinitelyTyped:
Given that, we've dropped official support for TS versions earlier than 5.0. (RTK may work with those versions, but we no longer test against them and won't try to fix issues with those versions.)
We'll continue to update our TS support matrix over time based on that 2-year rolling window.
What's Changed
window.rAF
later to allow fake timers to work correctly by @ ensconced in #4701OnQueryStarted
callbacks by @ aryaemami59 in #4713createAsyncThunk
without thewithTypes
method by @ EskiMojo14 in #4667isSuccess: true
when switching to an uninitialized cache entry by @ markerikson in #4731isSuccess
consistent when refetching after an error by @ markerikson in #4732Full Changelog: v2.3.0...v2.4.0
This feature release adds a new RTK Query
upsertQueryEntries
util to batch-upsert cache entries more efficiently, passes through additional values for use inprepareHeaders
, and exports additional TS types around query options and selectors.Changelog
upsertQueryEntries
RTK Query already had an
upsertQueryData
thunk that would upsert a single cache entry. However, some users wanted to upsert many cache entries (potentially hundreds or thousands), and found thatupsertQueryData
had poor performance in those cases. This is becauseupsertQueryData
runs the full async request handling sequence, including dispatching bothpending
andfulfilled
actions, each of which run the main reducer and update store subscribers. That means there's2N
store / UI updates per item, so upserting hundreds of items becomes extremely perf-intensive.RTK Query now includes an
api.util.upsertQueryEntries
action that is meant to handle the batched upsert use case more efficiently. It's a single synchronous action that accepts an array of many{endpointName, arg, value}
entries to upsert. This results in a single store update, making this vastly better for performance vs many individualupsertQueryData
calls.We see this as having two main use cases. The first is prefilling the cache with data retrieved from storage on app startup (and it's worth noting that
upsertQueryEntries
can accept entries for many different endpoints as part of the same array).The second is to act as a "pseudo-normalization" tool. RTK Query is not a "normalized" cache. However, there are times when you may want to prefill other cache entries with the contents of another endpoint, such as taking the results of a
getPosts
list endpoint response and prefilling the individualgetPost(id)
endpoint cache entries, so that components that reference an individual item endpoint already have that data available.Currently, you can implement the "pseudo-normalization" approach by dispatching
upsertQueryEntries
in an endpoint lifecycle, like this:endpoints: (build) => ({
getPosts: build.query<Post[], void>({
query: () => '/posts',
async onQueryStarted(_, { dispatch, queryFulfilled }) {
const res = await queryFulfilled
const posts = res.data
}),
})
Down the road we may add a new option to query endpoints that would let you provide the mapping function and have it automatically update the corresponding entries.
For additional comparisons between
upsertQueryData
andupsertQueryEntries
, see theupsertQueryEntries
API reference.prepareHeaders
OptionsThe
prepareHeaders
callback forfetchBaseQuery
now receives two additional values in theapi
argument:arg
: the URL string orFetchArgs
object that was passed in tofetchBaseQuery
for this endpointextraOptions
: any extra options that were provided to the base queryAdditional TS Types
We've added a
TypedQueryStateSelector
type that can be used to pre-type selectors for use withselectFromResult
:PostsApiResponse,
QueryArgument,
BaseQueryFunction,
SelectedResult
> = (state) => ({ posts: state.data?.posts ?? EMPTY_ARRAY })
function PostsList() {
const { posts } = useGetPostsQuery(undefined, {
selectFromResult: typedSelectFromResult,
})
}
We've also exported several additional TS types around base queries and tag definitions.
What's Changed
TypedQueryStateSelector
helper type by @ aryaemami59 in #4656Full Changelog: v2.2.8...v2.3.0
Important
Note: You are seeing this because you or someone else with access to this repository has authorized Snyk to open upgrade PRs.
For more information: