Skip to content

Releases: reduxjs/redux-toolkit

v2.3.0

14 Oct 21:28
@markerikson markerikson
v2.3.0
77fb33d
Compare
Choose a tag to compare
v2.3.0 Latest
Latest

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

Contributors

markerikson, phryneas, and 3 other contributors
Assets 2
Loading

RTK-Query OpenAPI Codegen v2.0.0

14 Oct 17:59
@markerikson markerikson
@rtk-query/[email protected]
b7b3df6
Compare
Choose a tag to compare
RTK-Query OpenAPI Codegen v2.0.0

This major release revamps the build and publishing setup for the RTK Query OpenAPI Codegen, as well as merging numerous PRs from external contributors.

This should resolve many outstanding issues and feature requests.

There were no changes from 2.0.0-alpha.0.

What's Changed

Contributors

FabianFrank, markerikson, and 11 other contributors
Assets 2
Loading
0 Join discussion

v2.2.8

08 Oct 03:20
@markerikson markerikson
v2.2.8
e7540a5
Compare
Choose a tag to compare
v2.2.8

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

Contributors

andrejpavlovic, phryneas, and 3 other contributors
Assets 2
Loading

RTK-Query OpenAPI Codegen v2.0.0-alpha.0

30 Aug 23:07
@markerikson markerikson
@rtk-query/[email protected]
8b32304
Compare
Choose a tag to compare
RTK-Query OpenAPI Codegen v2.0.0-alpha.0

This alpha release revamps the build and publishing setup for the RTK Query OpenAPI Codegen, as well as merging numerous PRs from external contributors.

This should resolve many outstanding issues and feature requests.

What's Changed

Contributors

FabianFrank, markerikson, and 11 other contributors
Assets 2
Loading
0 Join discussion

RTK-Query OpenAPI Codegen v1.2.0

30 Aug 23:05
@markerikson markerikson
@rtk-query/[email protected]
7536b8b
This commit was created on GitHub.com and signed with GitHub’s verified signature. The key has expired.
GPG key ID: 4AEE18F83AFDEB23
Expired
Learn about vigilant mode.
Compare
Choose a tag to compare
RTK-Query OpenAPI Codegen v1.2.0

This rolls up several existing minor releases:

1.2.0 - 2023-11-09

This version adds a new mergeReadWriteOnly configuration option (default to false) that, when set to true will not generate separate types for read-only and write-only properties.

1.1.3 - 2023-10-11

Added

1.1.2 - 2023-10-11

Added

  • Support for Read Only Properties in the Open API spec. Previously, this property was ignored.
    • Now if the readOnly property is present and set to true in a schema, it will split the type into two types: one with the read only property suffixed as 'Read' and the other without the read only properties, using the same type name as before.
    • This may cause issues if you had your OpenAPI spec properly typed/configured, as it will remove the read onyl types from your existing type. You will need to switch to the new type suffixed as 'Read' to avoid missing property names.

1.1.1 - 2023-10-11

Changed

Assets 2
Loading

RTK-Query OpenAPI Codegen v1.1.0

30 Aug 23:03
@markerikson markerikson
@rtk-query/[email protected]
81dd5b4
Compare
Choose a tag to compare
RTK-Query OpenAPI Codegen v1.1.0

Changelog

Added:

  • Option of generating real TS enums instead of string unions Adds the option of generating real TS enums instead of string unions #2854
  • Compatibility with TypeScript 5.x versions as the codegen relies on the TypeScript AST for code generation
    • As a result also needs a higher TypeScript version to work with (old version range was 4.1-4.5)
  • Changes dependency from a temporarily patched old version of oazapfts back to the current upstream version
Assets 2
Loading

v2.2.7

27 Jul 17:40
@markerikson markerikson
v2.2.7
75b4f69
Compare
Choose a tag to compare
v2.2.7

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:

Type error: The inferred type of 'configureStore' cannot be named without a reference to '@reduxjs/toolkit/node_modules/redux'. This is likely not portable. A type annotation is necessary.

@aryaemami59 did some deep investigation and concluded these were due to a mixture of using interface instead of type in 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 UpdateDefinitions and RetryOptions, per request.

listenerMiddleware.withTypes() methods now allow passing in an ExtraArgument generic.

What's Changed

Full Changelog: v2.2.6...v2.2.7

Contributors

joekrill, markerikson, and 2 other contributors
Assets 2
Loading

v2.2.6

29 Jun 11:10
@EskiMojo14 EskiMojo14
v2.2.6
a9362fb
Compare
Choose a tag to compare
v2.2.6

This bugfix release:

  • Brings internal useIsomorphicLayoutEffect usage in line with React Redux in React Native environments
  • Exports FetchBaseQueryArgs type
  • Fixes an issue in recent createEntityAdapter sorting perf improvements that could (in specific cases) cause Immer to throw an error

What's Changed

Full Changelog: v2.2.5...v2.2.6

Contributors

JacobShafer, WilsonCWong, and 2 other contributors
Assets 2
Loading

v2.2.5

16 May 07:04
@markerikson markerikson
v2.2.5
4578c74
Compare
Choose a tag to compare
v2.2.5

This bugfix release fixes an issue in the recent createEntityAdapter sorting perf improvements that could (in specific cases) cause Immer to throw an error when trying to read a plain JS value instead of a proxy-wrapped value.

What's Changed

  • Fix missed spot where use of current may fail if the value is not a draft by @markerikson in #4412

Full Changelog: v2.2.4...v2.2.5

Contributors

markerikson
Assets 2
Loading

v2.2.4

09 May 02:02
@markerikson markerikson
v2.2.4
0246f78
Compare
Choose a tag to compare
v2.2.4

This bugfix release improves sorting performance in createEntityAdapter, shrinks the code size in matcher utilities, fixes assorted issues with query hooks, and makes several TS tweaks.

Changelog

Entity Adapter Sorting Performance

Users reported in #4252 that the sorting performance of createEntityAdapter seemed abnormally bad - the provided comparison functions were being called far more times than expected.

Upon investigation, we had a couple of problems. We were always starting from an array that was in insertion order, not the existing sorted order, and that would always require significant effort to re-sort even if there weren't any actual changes to the sorted results. Also, the sorting checks required frequent access to Immer's Proxy-wrapped values, even in cases where all we needed was the plain state values for comparison purposes.

We've reworked the internal sorting logic to always start from the existing sorted array, do reads against a plain value to avoid the Proxy getter overhead where possible, and optimized inserts into existing sorted arrays. This should significantly speed up sorted entity adapter behavior.

Matcher Code Size Optimization

We've reworked the internals of the thunk-related matchers to deduplicate some of the logic, shaving a few bytes off the final bundle size.

RTK Query Hook Updates

defaultSerializeQueryArgs can now handle BigInt values safely.

The isLoading flag logic was improved to handle errors when a query hook tries to subscribe.

TS Updates

create.asyncThunk's types were improved to avoid cases where it might infer any.

We've made several internal types changes to work correctly with React 19's upcoming types.

The retryCondition method now receives unknown as an argument, instead of always assuming the user is using fetchBaseQuery.

Other Changes

The Reselect dep has been bumped to 5.1.0 to match the expected internal usage of createSelector.withTypes().

What's Changed

Full Changelog: v2.2.3...v2.2.4

Contributors

rkofman, markerikson, and 5 other contributors
Assets 2
Loading