chore(deps): bump @reduxjs/toolkit from 2.2.7 to 2.3.0

[dependabot]

Bumps @reduxjs/toolkit from 2.2.7 to 2.3.0.

Release notes

Sourced from @​reduxjs/toolkit's releases.

v2.3.0

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) =&gt; ({
          endpointName: 'getPost',
          arg: { id: post.id },
          value: post,
        })),
      ),
    )
  },
}),
getPost: build.query&lt;Post, Pick&lt;Post, 'id'&gt;&gt;({
  query: (post) =&gt; `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.

... (truncated)

Commits

• 77fb33d Release 2.3.0
• fa0906e Merge pull request #4291 from reduxjs/pr/fetchBaseQuery-extraOptions
• 896e4df Drop generic and make extraOptions unknown
• 41487fd Fix arguments type
• 1918f13 fix bad inference with an overload?
• 6ef362f fixup test
• 3e77381 fetchBaseQuery: expose extraOptions to prepareHeaders
• 7b50a61 Merge pull request #4561 from reduxjs/feature/4106-rtkq-normalization
• 3358c13 Fix Parameters headers
• d38ff98 Merge pull request #4638 from kyletsang/prepareheaders-args
• Additional commits viewable in compare view

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

---

Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR:

• @dependabot rebase will rebase this PR
• @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
• @dependabot merge will merge this PR after your CI passes on it
• @dependabot squash and merge will squash and merge this PR after your CI passes on it
• @dependabot cancel merge will cancel a previously requested merge and block automerging
• @dependabot reopen will reopen this PR if it is closed
• @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
• @dependabot show <dependency name> ignore conditions will show all of the ignore conditions of the specified dependency
• @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)

[github-actions]

Our Pull Request Approval Process

We have these basic policies to make the approval process smoother for our volunteer team.

Testing Your Code

Please make sure your code passes all tests. Our test code coverage system will fail if these conditions occur:

1. The overall code coverage drops below the target threshold of the repository
2. Any file in the pull request has code coverage levels below the repository threshold
3. Merge conflicts

The process helps maintain the overall reliability of the code base and is a prerequisite for getting your PR approved. Assigned reviewers regularly review the PR queue and tend to focus on PRs that are passing.

Reviewers

Do not assign reviewers. Our Queue Monitors will review your PR and assign them.
When your PR has been assigned reviewers contact them to get your code reviewed and approved via:

1. comments in this PR or
2. our slack channel

Reviewing Your Code

Your reviewer(s) will have the following roles:

1. arbitrators of future discussions with other contributors about the validity of your changes
2. point of contact for evaluating the validity of your work
3. person who verifies matching issues by others that should be closed.
4. person who gives general guidance in fixing your tests

CONTRIBUTING.md

Read our CONTRIBUTING.md file. Most importantly:

1. PRs with issues not assigned to you will be closed by the reviewer
2. Fix the first comment in the PR so that each issue listed automatically closes

Other

1. 🎯 Please be considerate of our volunteers' time. Contacting the person who assigned the reviewers is not advised unless they ask for your input. Do not @ the person who did the assignment otherwise.
2. Read the CONTRIBUTING.md file make