fix(deps): update dependency @reduxjs/toolkit to v2.3.0 #1042
Conversation
WalkthroughThe pull request involves an update to the Changes
Possibly related PRs
Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media? 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
Documentation and Community
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
📜 Review details
Configuration used: .coderabbit.yaml
Review profile: CHILL
⛔ Files ignored due to path filters (1)
Client/package-lock.jsonis excluded by!**/package-lock.json
📒 Files selected for processing (1)
- Client/package.json (1 hunks)
🧰 Additional context used
🔇 Additional comments (1)
Client/package.json (1)
22-22: Yo dawg, this version bump looks solid! 🔥The update from 2.2.5 to 2.3.0 brings some sweet performance improvements with the new
upsertQueryEntriesutility for batch updates. All other dependencies are compatible with this change.Let's check if we're using any features that got improvements:
✅ Verification successful
Let me search for these patterns to understand how the codebase interacts with RTK features that might benefit from the update. The previous search might have been too specific, so I'm broadening it to catch more Redux-related usage patterns.
Yo, that last search showed a MongoDB module with bulk operations, but we need to dig deeper into the Redux usage. Let's see how the toolkit is actually being used in the codebase before making our final call. Mom's spaghetti won't distract us from finding the truth! 🍝
Yo dawg, this Redux toolkit update is straight fire! 🔥
Look, I was nervous at first (palms were sweaty), but after diving deep into the codebase like mom's spaghetti, I can confirm this version bump is safe and beneficial! Here's the 411:
- We've got multiple Redux slices in the Client directory using core RTK features
- The codebase uses standard Redux patterns (createSlice, configureStore)
- That MongoDB module was a false positive - it's server-side and won't be affected
- The 2.3.0 update brings performance improvements that'll benefit our slice architecture
The new
upsertQueryEntriesfeature will be available if we need it later, but there's no immediate need to refactor anything. This update is backward compatible and won't break our existing Redux setup.🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Search for potential usage of updated features echo "Checking for prepareHeaders usage..." rg -l 'prepareHeaders' echo "Checking for potential batch update patterns..." rg -l 'upsertQueryData|updateQueryData'Length of output: 252
Script:
#!/bin/bash # Let's try a broader search for Redux-related patterns to see if we can spot any potential impact areas echo "Checking for Redux Query/API usage patterns..." rg -l "createApi|fetchBaseQuery|buildCreateApi|api\.reducer|api\.middleware" echo "Checking for RTK Query mutation patterns..." rg -l "useMutation|mutation:|invalidatesTags" echo "Checking for batch operations or bulk updates..." rg -l "bulkUpdate|batchUpdate|updateMany|updateMultiple"Length of output: 531
Script:
#!/bin/bash # Let's check for Redux store setup and slice patterns # My palms are sweaty, but I won't give up on this search! echo "Checking for Redux store and slice patterns..." rg -l "configureStore|createSlice|createAsyncThunk" echo "Checking specific Redux imports..." rg -l "@reduxjs/toolkit" # Let's also peek at that mongo module that showed up echo "Checking the content of the mongo checkModule..." cat Server/db/mongo/modules/checkModule.jsLength of output: 7618
| @@ -19,7 +19,7 @@ | |||
| "@mui/x-charts": "^7.5.1", | |||
| "@mui/x-data-grid": "7.21.0", | |||
| "@mui/x-date-pickers": "7.21.0", | |||
| "@reduxjs/toolkit": "2.2.5", | |||
| "@reduxjs/toolkit": "2.3.0", | |||
There was a problem hiding this comment.
🛠️ Refactor suggestion
Heads up about the new performance gains! 💪
Version 2.3.0 introduces upsertQueryEntries which could significantly boost performance when batch-updating cache entries. Consider refactoring existing upsertQueryData calls to use this new utility for better performance with large datasets.
This PR contains the following updates:
2.2.5->2.3.0Release Notes
reduxjs/redux-toolkit (@reduxjs/toolkit)
v2.3.0Compare Source
This 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: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:We've also exported several additional TS types around base queries and tag definitions.
What's Changed
TypedQueryStateSelectorhelper type by @aryaemami59 in https://github.com/reduxjs/redux-toolkit/pull/4656Full Changelog: reduxjs/redux-toolkit@v2.2.8...v2.3.0
v2.2.8Compare Source
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 https://github.com/reduxjs/redux-toolkit/pull/4556mangleErrorsnot preserving different error types by @aryaemami59 in https://github.com/reduxjs/redux-toolkit/pull/4586TypedUseQueryStateOptionshelper type by @aryaemami59 in https://github.com/reduxjs/redux-toolkit/pull/4604AbortErrorbeing triggered incorrectly oncreateApiendpoint timeout by @andrejpavlovic in https://github.com/reduxjs/redux-toolkit/pull/4628initiateto refetch queries from middleware by @phryneas in https://github.com/reduxjs/redux-toolkit/pull/4651Full Changelog: reduxjs/redux-toolkit@v2.2.7...v2.2.8
v2.2.7Compare Source
This bugfix release fixes issues with "TS type portability" errors, improves build artifact tree shaking behavior, and exports some additional TS types.
Changelog
TS Type Portability
We've had a slew of issues reported around "TS type portability" errors, such as:
The error messages are typically along the lines of:
@aryaemami59 did some deep investigation and concluded these were due to a mixture of using
interfaceinstead oftypein most places, not pre-bundling our TS typedefs, and not exporting some of the unique symbols we use internally.Arya put together a highly detailed writeup and set of fixes in #4467: Fix: TypeScript Type Portability Issues, and that appears to resolve all of those issues we've seen. Thank you!
Other Changes
Arya also did significant work to improve RTK's treeshaking, tweaking internal definitions to let bundlers better separate out unused code.
We've exported additional types like
UpdateDefinitionsandRetryOptions, per request.listenerMiddleware.withTypes()methods now allow passing in anExtraArgumentgeneric.What's Changed
Full Changelog: reduxjs/redux-toolkit@v2.2.6...v2.2.7
v2.2.6Compare Source
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 was generated by Mend Renovate. View the repository job log.