kjuulh/todo
1
0
Fork 0
Code Issues 1 Pull Requests Projects Releases Wiki Activity

fix(deps): update dependency @reduxjs/toolkit to v2.3.0 #366

Merged
kjuulh merged 1 commits from renovate/all into main 2024-10-15 06:56:52 +02:00
Conversation 0 Commits 1 Files Changed 2 +5 -5
kjuulh commented 2024-10-15 02:58:09 +02:00
Owner
Copy Link

This PR contains the following updates:

Package Type Update Change
@reduxjs/toolkit (source) dependencies minor 2.2.8 -> 2.3.0

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: https://github.com/reduxjs/redux-toolkit/compare/v2.2.8...v2.3.0

Configuration

📅 Schedule: Branch creation - At any time (no schedule defined), Automerge - At any time (no schedule defined).

🚦 Automerge: Enabled.

♻ 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.

This PR contains the following updates: | Package | Type | Update | Change | |---|---|---|---| | [@reduxjs/toolkit](https://redux-toolkit.js.org) ([source](https://github.com/reduxjs/redux-toolkit)) | dependencies | minor | [`2.2.8` -> `2.3.0`](https://renovatebot.com/diffs/npm/@reduxjs%2ftoolkit/2.2.8/2.3.0) | --- ### Release Notes <details> <summary>reduxjs/redux-toolkit (@&#8203;reduxjs/toolkit)</summary> ### [`v2.3.0`](https://github.com/reduxjs/redux-toolkit/releases/tag/v2.3.0) [Compare Source](https://github.com/reduxjs/redux-toolkit/compare/v2.2.8...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](https://redux-toolkit.js.org/rtk-query/usage/cache-behavior#no-normalized-or-de-duplicated-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: ```ts 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](https://redux-toolkit.js.org/rtk-query/api/created-api/api-slice-utils#upsertqueryentries). ##### `prepareHeaders` Options The [`prepareHeaders` callback for `fetchBaseQuery`](https://redux-toolkit.js.org/rtk-query/api/fetchBaseQuery#prepareheaders) 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`: ```ts 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 - Fix serializeQueryArgs type by [@&#8203;Reedgern](https://github.com/Reedgern) in https://github.com/reduxjs/redux-toolkit/pull/4658 - Add the `TypedQueryStateSelector` helper type by [@&#8203;aryaemami59](https://github.com/aryaemami59) in https://github.com/reduxjs/redux-toolkit/pull/4656 - Pass query args to prepareHeaders function by [@&#8203;kyletsang](https://github.com/kyletsang) in https://github.com/reduxjs/redux-toolkit/pull/4638 - Implement a util function to batch-upsert cache entries by [@&#8203;markerikson](https://github.com/markerikson) in https://github.com/reduxjs/redux-toolkit/pull/4561 - fetchBaseQuery: expose extraOptions to prepareHeaders by [@&#8203;phryneas](https://github.com/phryneas) in https://github.com/reduxjs/redux-toolkit/pull/4291 **Full Changelog**: https://github.com/reduxjs/redux-toolkit/compare/v2.2.8...v2.3.0 </details> --- ### Configuration 📅 **Schedule**: Branch creation - At any time (no schedule defined), Automerge - At any time (no schedule defined). 🚦 **Automerge**: Enabled. ♻ **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. --- - [ ] <!-- rebase-check -->If you want to rebase/retry this PR, check this box --- This PR has been generated by [Renovate Bot](https://github.com/renovatebot/renovate). <!--renovate-debug:eyJjcmVhdGVkSW5WZXIiOiIzNy40MjQuMyIsInVwZGF0ZWRJblZlciI6IjM3LjQyNC4zIiwidGFyZ2V0QnJhbmNoIjoibWFpbiIsImxhYmVscyI6W119-->
kjuulh added 1 commit 2024-10-15 02:58:10 +02:00
fix(deps): update dependency @reduxjs/toolkit to v2.3.0
All checks were successful
continuous-integration/drone/pr Build is passing
Details
continuous-integration/drone/push Build is passing
Details
de6e130dca
kjuulh merged commit de6e130dca into main 2024-10-15 06:56:52 +02:00
Sign in to join this conversation.
Reviewers
No reviewers
Labels
Clear labels
No items
No Label
Milestone
Clear milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
No Assignees
1 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: kjuulh/todo#366
No description provided.
Delete Branch "renovate/all"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?