Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

fix(deps): update dependency @reduxjs/toolkit to v2.3.0 j:kit-282 #4722

Merged
merged 1 commit into from
Nov 26, 2024

Conversation

renovate-coveo[bot]
Copy link
Contributor

This PR contains the following updates:

Package Change Age Adoption Passing Confidence
@reduxjs/toolkit (source) 2.2.7 -> 2.3.0 age adoption passing confidence

Release Notes

reduxjs/redux-toolkit (@​reduxjs/toolkit)

v2.3.0

Compare Source

This feature release adds a new RTK Query upsertQueryEntries util to batch-upsert cache entries more efficiently, passes through additional values for use in prepareHeaders, 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 that upsertQueryData had poor performance in those cases. This is because upsertQueryData runs the full async request handling sequence, including dispatching both pending and fulfilled actions, each of which run the main reducer and update store subscribers. That means there's 2N 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 individual upsertQueryData 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 individual getPost(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:

const api = createApi({
  endpoints: (build) => ({
    getPosts: build.query<Post[], void>({
      query: () => '/posts',
      async onQueryStarted(_, { dispatch, queryFulfilled }) {
        const res = await queryFulfilled
        const posts = res.data

        // Pre-fill the individual post entries with the results
        // from the list endpoint query
        dispatch(
          api.util.upsertQueryEntries(
            posts.map((post) => ({
              endpointName: 'getPost',
              arg: { id: post.id },
              value: post,
            })),
          ),
        )
      },
    }),
    getPost: build.query<Post, Pick<Post, 'id'>>({
      query: (post) => `post/${post.id}`,
    }),
  }),
})

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 and upsertQueryEntries, see the upsertQueryEntries API reference.

prepareHeaders Options

The prepareHeaders callback for fetchBaseQuery now receives two additional values in the api argument:

  • arg: the URL string or FetchArgs object that was passed in to fetchBaseQuery for this endpoint
  • extraOptions: any extra options that were provided to the base query
Additional TS Types

We've added a TypedQueryStateSelector type that can be used to pre-type selectors for use with selectFromResult:

const typedSelectFromResult: TypedQueryStateSelector<
  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

Full Changelog: reduxjs/redux-toolkit@v2.2.8...v2.3.0

v2.2.8

Compare 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 queryCacheKey value 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

Full Changelog: reduxjs/redux-toolkit@v2.2.7...v2.2.8


Configuration

📅 Schedule: Branch creation - "before 4:00am on Tuesday" in timezone America/Toronto, 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.


  • If you want to rebase/retry this PR, check this box

This PR has been generated by Renovate Bot.

@renovate-coveo renovate-coveo bot requested a review from a team as a code owner November 26, 2024 08:29
@renovate-coveo renovate-coveo bot added the dependencies Pull requests that update a dependency file label Nov 26, 2024
Copy link

Pull Request Report

PR Title

✅ Title follows the conventional commit spec.

Live demo links

Bundle Size

File Old (kb) New (kb) Change (%)
case-assist 241.4 242.6 0.5
commerce 346 347.3 0.4
search 412.5 413.8 0.3
insight 403.7 404.9 0.3
recommendation 253.6 254.9 0.5
ssr 406 407.3 0.3
ssr-commerce 358.3 359.6 0.4

SSR Progress

Use case SSR (#) CSR (#) Progress (%)
search 39 44 89
recommendation 0 4 0
case-assist 0 6 0
insight 0 27 0
commerce 0 15 0
Detailed logs search : buildInteractiveResult
search : buildInteractiveInstantResult
search : buildInteractiveRecentResult
search : buildInteractiveCitation
search : buildGeneratedAnswer
recommendation : missing SSR support
case-assist : missing SSR support
insight : missing SSR support
commerce : missing SSR support

@alexprudhomme alexprudhomme added this pull request to the merge queue Nov 26, 2024
Merged via the queue into master with commit e14a2e8 Nov 26, 2024
123 checks passed
@alexprudhomme alexprudhomme deleted the renovate/redux branch November 26, 2024 13:28
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
dependencies Pull requests that update a dependency file
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant