[Snyk] Upgrade @reduxjs/toolkit from 2.2.7 to 2.3.0 #837
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Snyk has created this PR to upgrade @reduxjs/toolkit from 2.2.7 to 2.3.0. See this package in npm: @reduxjs/toolkit See this project in Snyk: https://app.snyk.io/org/hybrid-cloud-experience-red-hat-insights/project/90a167a6-51ac-48bc-a9a8-731ab83f03f5?utm_source=github&utm_medium=referral&page=upgrade-pr
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## master #837 +/- ##
======================================
Coverage 8.27% 8.27%
======================================
Files 68 68
Lines 3953 3953
Branches 864 864
======================================
Hits 327 327
Misses 3626 3626 ☔ View full report in Codecov by Sentry. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.2.7 to 2.3.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 2 versions ahead of your current version.
The recommended version was released on 22 days ago.
Release notes
Package name: @reduxjs/toolkit
-
2.3.0 - 2024-10-14
const api = createApi({
const typedSelectFromResult: TypedQueryStateSelector<
- Fix serializeQueryArgs type by @ Reedgern in #4658
- Add the
- Pass query args to prepareHeaders function by @ kyletsang in #4638
- Implement a util function to batch-upsert cache entries by @ markerikson in #4561
- fetchBaseQuery: expose extraOptions to prepareHeaders by @ phryneas in #4291
-
2.2.8 - 2024-10-08
- Export
- Fix
- Add the
- feat(baseQuery): expose queryCacheKey in baseQuery by @ HaakonSvane in #4636
- Fix
- type: export QueryReturnValue by @ hornta in #4640
- call
-
2.2.7 - 2024-07-27
from @reduxjs/toolkit GitHub release notesThis feature release adds a new RTK Query
upsertQueryEntriesutil 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
upsertQueryEntriesRTK Query already had an
upsertQueryDatathunk that would upsert a single cache entry. However, some users wanted to upsert many cache entries (potentially hundreds or thousands), and found thatupsertQueryDatahad poor performance in those cases. This is becauseupsertQueryDataruns the full async request handling sequence, including dispatching bothpendingandfulfilledactions, each of which run the main reducer and update store subscribers. That means there's2Nstore / UI updates per item, so upserting hundreds of items becomes extremely perf-intensive.RTK Query now includes an
api.util.upsertQueryEntriesaction 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 individualupsertQueryDatacalls.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
upsertQueryEntriescan 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
getPostslist 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
upsertQueryEntriesin 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
upsertQueryDataandupsertQueryEntries, see theupsertQueryEntriesAPI reference.prepareHeadersOptionsThe
prepareHeaderscallback forfetchBaseQuerynow receives two additional values in theapiargument:arg: the URL string orFetchArgsobject that was passed in tofetchBaseQueryfor this endpointextraOptions: any extra options that were provided to the base queryAdditional TS Types
We've added a
TypedQueryStateSelectortype 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
TypedQueryStateSelectorhelper type by @ aryaemami59 in #4656Full Changelog: v2.2.8...v2.3.0
This bugfix release fixes a long-standing issue with RTK Query lazy query triggers returning stale data in some cases, fixes an error handling issue in RTK Query, and exports additional TS types.
Changelog
Lazy Query Trigger Handling
We'd had a couple long-standing issues reporting that
const result = await someLazyQueryTrigger()sometimes returned stale data, especially if a mutation had just invalidated that query's tag.We finally got a good repro of this issue and identified it as a mis-written call inside of the middleware that skipped past the necessary handling to activate the correct query status tracking in that scenario. This should now be fixed.
Other Changes
Timeout handling in RTKQ endpoints should now correctly throw a timeout-related error instead of an
AbortError.Base queries now have access to the current
queryCacheKeyvalue so it can be used in deciding query logic.We've exported several more TS types related to query options, as some users have been depending on those even though they previously weren't part of the public API.
What's Changed
QueryExtraOptionsandMutationExtraOptionsby @ aryaemami59 in #4556mangleErrorsnot preserving different error types by @ aryaemami59 in #4586TypedUseQueryStateOptionshelper type by @ aryaemami59 in #4604AbortErrorbeing triggered incorrectly oncreateApiendpoint timeout by @ andrejpavlovic in #4628initiateto refetch queries from middleware by @ phryneas in #4651Full Changelog: v2.2.7...v2.2.8
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: