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

[Snyk] Upgrade @reduxjs/toolkit from 2.3.0 to 2.4.0 #434

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

clarin-bot
Copy link
Collaborator

snyk-top-banner

Snyk has created this PR to upgrade @reduxjs/toolkit from 2.3.0 to 2.4.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 1 version ahead of your current version.

  • The recommended version was released 21 days ago.

Release notes
Package name: @reduxjs/toolkit
  • 2.4.0 - 2024-11-28

    This feature release includes multiple tweaks and fixes to RTK Query functionality, additional exported TS types, and drops support for TS versions earlier than 5.0.

    Changelog

    RTK Query Improvements

    Lazy query hooks can now be reset.

    retry.fail now accepts meta as a second argument.

    Tag invalidation arrays now ignore nullish values.

    We did some small internal refactoring around Maps and default values that shrank bundle size slightly.

    Bugfixes

    Passing skipToken to a query hook now bails out before running any other logic, which fixes cases where serializeQueryArgs previously threw an error because there were no args to process.

    The autoBatchEnhancer now reads window.requestAnimationFrame later, which it to work properly with Jest fake timers.

    We fixed cases where the hook result isSuccess flag would briefly flicker to false when switched to a different cache entry that was uninitialized, and would briefly flicker to true when refetching a query that previously errored.

    The listener middleware previously had inconsistent logic checks for comparing against existing listener entries (effect + type, vs effect only). It now always checks both effect + type.

    Additional TS Types

    We now export Typed[Query|Mutation]OnQueryStarted helpers to let you define onQueryStarted callbacks outside of createApi if desired.

    We also now export a CreateAsyncThunkFunction type that can be used to type userland wrappers around createAsyncThunk.

    TS Support Matrix Updates

    We've historically tried to maintain TS backwards compatibility as long as possible, and made occasional updates to our TS support matrix in minor versions over time. As of RTK 2.3.0, we officially supported back through TS 4.7.

    As of this release, we're tweaking that support policy to match the policy used by DefinitelyTyped:

    Definitely Typed only tests packages on versions of TypeScript that are less than 2 years old
    image

    Given that, we've dropped official support for TS versions earlier than 5.0. (RTK may work with those versions, but we no longer test against them and won't try to fix issues with those versions.)

    We'll continue to update our TS support matrix over time based on that 2-year rolling window.

    What's Changed

    • add example to reproduce defect of serializeQueryArgs with skipToken by @ Themezv in #4708
    • Read window.rAF later to allow fake timers to work correctly by @ ensconced in #4701
    • Add type helpers for OnQueryStarted callbacks by @ aryaemami59 in #4713
    • Add a type for createAsyncThunk without the withTypes method by @ EskiMojo14 in #4667
    • Add ability to reset lazy query hooks by @ alexmotoc in #4689
    • Ignore nullish values in tag invalidations by @ pierroberto in #4671
    • Allow passing meta to retry.fail, and passing baseQuery to ensure types match by @ EskiMojo14 in #4723
    • Keep isSuccess: true when switching to an uninitialized cache entry by @ markerikson in #4731
    • Keep isSuccess consistent when refetching after an error by @ markerikson in #4732
    • Update to new version of upsert proposal, and fix listener equality checks by @ EskiMojo14 in #4735

    Full Changelog: v2.3.0...v2.4.0

  • 2.3.0 - 2024-10-14

    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

        <span class="pl-c">// Pre-fill the individual post entries with the results</span>
        <span class="pl-c">// from the list endpoint query</span>
        <span class="pl-en">dispatch</span><span class="pl-kos">(</span>
          <span class="pl-s1">api</span><span class="pl-kos">.</span><span class="pl-c1">util</span><span class="pl-kos">.</span><span class="pl-en">upsertQueryEntries</span><span class="pl-kos">(</span>
            <span class="pl-s1">posts</span><span class="pl-kos">.</span><span class="pl-en">map</span><span class="pl-kos">(</span><span class="pl-kos">(</span><span class="pl-s1">post</span><span class="pl-kos">)</span> <span class="pl-c1">=&gt;</span> <span class="pl-kos">(</span><span class="pl-kos">{</span>
              <span class="pl-c1">endpointName</span>: <span class="pl-s">'getPost'</span><span class="pl-kos">,</span>
              <span class="pl-c1">arg</span>: <span class="pl-kos">{</span> <span class="pl-c1">id</span>: <span class="pl-s1">post</span><span class="pl-kos">.</span><span class="pl-c1">id</span> <span class="pl-kos">}</span><span class="pl-kos">,</span>
              <span class="pl-c1">value</span>: <span class="pl-s1">post</span><span class="pl-kos">,</span>
            <span class="pl-kos">}</span><span class="pl-kos">)</span><span class="pl-kos">)</span><span class="pl-kos">,</span>
          <span class="pl-kos">)</span><span class="pl-kos">,</span>
        <span class="pl-kos">)</span>
      <span class="pl-kos">}</span><span class="pl-kos">,</span>
    <span class="pl-kos">}</span><span class="pl-kos">)</span><span class="pl-kos">,</span>
    <span class="pl-c1">getPost</span>: <span class="pl-s1">build</span><span class="pl-kos">.</span><span class="pl-en">query</span><span class="pl-c1">&lt;</span><span class="pl-smi">Post</span><span class="pl-kos">,</span> <span class="pl-smi">Pick</span><span class="pl-c1">&lt;</span><span class="pl-smi">Post</span><span class="pl-kos">,</span> <span class="pl-s">'id'</span><span class="pl-c1">&gt;</span><span class="pl-c1">&gt;</span><span class="pl-kos">(</span><span class="pl-kos">{</span>
      <span class="pl-en">query</span>: <span class="pl-kos">(</span><span class="pl-s1">post</span><span class="pl-kos">)</span> <span class="pl-c1">=&gt;</span> <span class="pl-s">`post/<span class="pl-s1"><span class="pl-kos">${</span><span class="pl-s1">post</span><span class="pl-kos">.</span><span class="pl-c1">id</span><span class="pl-kos">}</span></span>`</span><span class="pl-kos">,</span>
    <span class="pl-kos">}</span><span class="pl-kos">)</span><span class="pl-kos">,</span>
    

    }),
    })

    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: v2.2.8...v2.3.0

from @reduxjs/toolkit GitHub release notes

Important

  • Check the changes in this PR to ensure they won't cause issues with your project.
  • This PR was automatically created by Snyk using the credentials of a real user.

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:

Snyk has created this PR to upgrade @reduxjs/toolkit from 2.3.0 to 2.4.0.

See this package in npm:
@reduxjs/toolkit

See this project in Snyk:
https://app.snyk.io/org/clarin-eric/project/7e36aabb-988e-4f86-97cd-167d3eb49c71?utm_source=github&utm_medium=referral&page=upgrade-pr
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants