reduxjs/redux-toolkit
 Watch   
 Star   
 Fork   
简介统计版本
13 days ago
redux-toolkit
reduxjs

v2.12.0

This feature release adds RTK usage skills files (via TanStack Intent) exports the RTK Query hook options types for reusability, fixes issues with infinite query status flags and batching handling, and makes some small TS improvements.

Changelog

Skills Files

We've generated agent skill files that are now included in the RTK package itself in a skills folder. They cover using and migrating to modern RTK, client and server state management, and handling side effects. You can point your agent at these skills yourself, or use TanStack Intent to pick them up.

TypeScript Improvements

The types for our RTK Query hook options are now exported, which lets you stop using Parameters to extract those types for use in your own code.

The types for listener middleware matchers were tweaked to allow interface-based type guards, not just type-based definitions.

The internal IgnorePaths type was renamed to IgnoredPaths for consistency.

We now use the built-in NoInfer util that comes with TS 5.4+.

Fixes

We fixed handling of the isSuccess status flag when switching infinite query cache entries. This should prevent accidental UI flashes that were occurring due to this flag accidentally flipping.

We've added a 100ms timeout fallback to the autoBatch enhancer's requestAnimationFrame timer. We had several reports that rAF didn't work correctly when used in background tabs / opened windows, and that RTK never updated the UI. This should ensure that the updates flush correctly.

What's Changed

Full Changelog: https://github.com/reduxjs/redux-toolkit/compare/v2.11.2...v2.12.0

2025-12-15 05:54:57
redux-toolkit
reduxjs

v2.11.2

This bugfix release updates the AbortSignal handling to fall back if DOMException isn't available (such as RN environments), and updates the TypedUseInfiniteQueryHookResult type to correctly include fetchNextPage/fetchPreviousPage fields.

Changelog

Bugfixes

The AbortSignal changes in 2.11.1 used DOMException in a couple places to match the expected behavior of AbortSignal, but turns out that's not available in environments like React Native. We've updated the logic to fall back to a plain Error if DOMException isn't available.

The TypedUseInfiniteQueryHookResult type wasn't correctly including the fetchNextPage/fetchPreviousPage fields, and now it does.

What's Changed

Full Changelog: https://github.com/reduxjs/redux-toolkit/compare/v2.11.1...v2.11.2

2025-12-08 11:39:32
redux-toolkit
reduxjs

v2.11.1

This bugfix release fixes an issue with our internal AbortSignal handling that was reported as causing an error in a rare reset situation. We've also restructured our publishing process to use NPM Trusted Publishing, and updated our TS support matrix to only support TS 5.4+.

Changelog

Publishing Changes

We've previously done most of our releases semi-manually locally, with various release process CLI tools. With the changes to NPM publishing security and the recent wave of NPM attacks, we've updated our publishing process to solely use NPM Trusted Publishing via workflows. We've also done a hardening pass on our own CI setup.

We had done a couple releases via CI workflows previously, and later semi-manual releases caused PNPM to warn that RTK was no longer trusted. This release should be trusted and will resolve that issue.

Thanks to the e18e folks and their excellent guide at https://e18e.dev/docs/publishing for making this process easier!

TS Support Matrix Updates

We've previously mentioned rolling changes to our TS support matrix in release notes, but didn't officially document our support policy. We've added a description of the support policy (last 2 years of TS releases, matching DefinitelyTyped) and the current oldest TS version we support in the docs:

As of today, we've updated the support matrix to be TS 5.4+ . As always, it's possible RTK will work if you're using an earlier version of TS, but we don't test against earlier versions and don't support any issues with those versions.

We have run an initial test with the upcoming TS 7.0 native tsgo release. We found a couple minor issues with our own TS build and test setup, but no obvious issues with using RTK with TS 7.0.

Bug Fixes

A user reported a rare edge case where the combination of resetApiState and retry() could lead to an error calling an AbortController. We've restructured our AbortController handling logic to avoid that (and simplified a bit of our internals in the process).

What's Changed

Full Changelog: https://github.com/reduxjs/redux-toolkit/compare/v2.11.0...v2.11.1

2025-12-08 08:22:16
redux-toolkit
reduxjs

@rtk-query/codegen-openapi@2.2.0

This feature release adds new RTKQ codegen config options for outputting regex constants when the pattern keyword is used in an OpenAPI definition, and defining explicit tag overrides on a per-endpoint basis as part of the codegen config.

What's Changed

Full Changelog: https://github.com/reduxjs/redux-toolkit/compare/@rtk-query/codegen-openapi@2.1.0...@rtk-query/codegen-openapi@2.2.0

2025-11-24 07:00:47
redux-toolkit
reduxjs

v2.11.0

This feature release upgrades our Immer dependency to v11 to pick up the additional recent performance optimizations, adds a new refetchCachedPages option to allow only fetching the first cached page, and fixes an issue with regex ignore paths in the immutability middleware.

Changelog

Immer v11 Performance Improvements

As described in the release notes for v2.10.0, we recently put significant effort into profiling Immer, and contributed several PRs that aimed to optimize its update performance.

v2.10.0 included Immer 10.2.0, which included the first smaller set of perf updates. That included a new Immer option to disable "strict iteration" to speed up iterating copied objects, and we specifically applied that change in RTK under the assumption that standard plain JS objects as Redux state shouldn't have unusual keys anyway. Overall, this appears to boost Immer update perf by ~+20% over v10.1 depending on update scenario.

Immer v11.0.0 was just released and contains the second perf PR, a major internal architectural rewrite to change the update finalization implementation from a recursive tree traversal to a set of targeted updates based on accessed and updated fields. Based on the benchmarks in the PR, this adds another ~+5% perf boost over the improvements in v10.2, again with variations depending on update scenario. In practice, the actual improvement may be better than that - the benchmarks list includes some array update cases which actually got a bit slower (and thus drag down the overall average), and a majority of update scenarios show anywhere from +25% to +60% faster than Immer v10.1!

As a practical example, we have an RTK Query stress test benchmark where we mount 1000 components with query hooks at once, unmount, then remount them. We ran the same benchmark steps for RTK 2.9 and Immer 10.1, and then RTK 2.10+ and Immer 11. The overall scripting time dropped by about 30% (3330ms -> 2350ms), and the amount of time spent in Immer methods and the RTK reducers dropped significantly:

image

Based on this, it appears to be a major improvement overall.

As with the instructions in v2.10.0: if by some chance your Redux app state relies on non-string keys, you can still manually call setUseStrictIteration(true) in your app code to retain compatibility there, but we don't expect that standard Redux apps will have to worry about that.

There are still two outstanding Immer perf PRs that may offer further improvements: one that adds an optional plugin to override array methods to avoid proxy creation overhead, and another experimental tweak to shallow copying that may be better with larger object sizes.

New refetchCachedPages Option

RTK Query's infinite query API was directly based on React Query's approach, including the pages cache structure and refetching behavior. By default, that means that when you trigger a refetch, both R-Q and RTKQ will try to sequentially refetch all pages currently in that cache entry. So, if there were 5 pages cached for an entry, they will try to fetch pages 0...4, in turn.

Some users have asked for the ability to only refetch the first page. This can be accomplished somewhat manually by directly updating the cache entry to eliminate the old pages and then triggering a refetch, but that's admittedly not very ergonomic.

We've merged a contributed PR that adds a new refetchCachedPages flag. This can be defined as part of infinite query endpoints, passed as an option to infinite query hooks, or passed as an option in initiate() calls or hook refetch() methods. If set to refetchCachedPages: false, it will only refetch the first page in the cache and not the remaining pages, thus shrinking the cache from N pages to 1 page.

Other Fixes

We merged a fix to the immutability dev middleware where it was treating ignoredPath regexes as strings and not actually testing them correctly.

What's Changed

Full Changelog: https://github.com/reduxjs/redux-toolkit/compare/v2.10.1...v2.11.0

2025-11-04 23:35:12
redux-toolkit
reduxjs

v2.10.1

This bugfix release fixes an issue with window access breaking in SSR due to the byte-shaving work in 2.10.

What's Changed

Full Changelog: https://github.com/reduxjs/redux-toolkit/compare/v2.10.0...v2.10.1

2025-11-04 10:04:01
redux-toolkit
reduxjs

v2.10.0

This feature release updates our Immer dep to 10.2 to pick up its performance improvements, has additional byte-shaving and internal performance updates, and fixes a combineSlices type issue.

Changelog

Immer Performance Improvements

Redux Toolkit has been built around Immer since the very first prototype in 2018. Use of Immer as the default in createSlice directly eliminated accidental mutations as a class of errors in Redux apps, and drastically simplified writing immutable updates in reducers.

We've had various issues filed over the years asking to make Immer optional, or raising concerns about Immer's perf. Immer is indeed slower than writing immutable updates by hand, but our stance has always been that Immer's DX is absolutely worth whatever modest perf cost it might incur, and that reducers are usually not the bottleneck in Redux apps anyway - it's usually the cost of updating the UI that's more expensive.

However, a year ago an issue was filed with some specific complaints about Immer perf being very slow. We investigated, ran benchmarks, and filed an Immer issue confirming that it had gotten noticeably slower over time. Immer author Michel Weststrate agreed, and said there were some potential tweaks and architectural changes that could be made, but didn't have time to look into them himself.

A couple months ago, we started investigating possible Immer perf improvements ourselves, including profiling various scenarios and comparing implementations of other similar immutable update libraries. After extensive research and development, we were able to file several PRs to improve Immer's perf: a set of smaller tweaks around iteration and caching, a couple much larger architectural changes, and a potential change to copying objects.

Immer 10.2.0 contains the first set of smaller perf improvements, and this RTK release updates our dependency to 10.2 to pick up those changes.

One important behavior note here: Earlier versions of Immer (8, 9, 10.1) added more handling for edge cases like symbol keys in objects. These changes made sense for correctness, but also contributed to the slowdown. Immer 10.2 now includes a new setUseStrictIteration option to allow only copying string keys in objects (using Object.keys() instead of Reflect.ownKeys()), but keeps the option as strict: true for compatibility with its own users. That default will likely change in Immer 11.

For RTK 2.10.0, we specifically import and call setUseStrictIteration(false), under the assumption that standard Redux state usage only involves string keys in plain JS objects! This should provide a ~10% speedup for Immer update operations. Given that expectation, we believe this is a reasonable feature change and only needs a minor version bump.

If by some chance you are using symbol keys in your Redux state, or in other Immer-powered updates in your Redux app, you can easily revert to the previous behavior by calling setUseStrictIteration(true) in your own app code.

Based on discussions with Michel, Immer v11 should come out in the near future with additional architectural changes for better perf, including optional support for faster array methods that would be available as an Immer plugin adding ~2KB bundle size. We will likely not turn that plugin on by default, but recommend that users enable it if they do frequent array ops in reducers.

We're happy to have contributed these perf improvements to Immer, and that they will benefit not just RTK users but all Immer users everywhere!

You can follow the additional discussion and progress updates in the main Immer perf update tracking issue.

Additional RTK Perf Improvements

We've tweaked some places where we were doing repeated filter().map().map() calls to micro-optimize those loops.

RTKQ tag invalidation was always reading from proxy-wrapped arrays when rewriting provided tags. It now reads from the plain arrays instead, providing a modest speedup.

We previously found that ESBuild wasn't deduplicating imports from the same libraries in separate files bundled together (ie import { useEffect as useEffect2/3/4/ } from 'react'). We've restructured our internals to ensure all external imports are only pulled in once.

We've done some extensive byte-shaving in various places in the codebase. The byte-shaving and import deduplication saves about 0.6K min from the RTKQ core, and 0.2K min from the RTKQ React bundle.

Other Changes

combineSlices now better handles cases where PreloadedState might not match the incoming type, such as persisted values.

What's Changed

Full Changelog: https://github.com/reduxjs/redux-toolkit/compare/v2.9.2...v2.10.0

2025-10-23 04:35:27
redux-toolkit
reduxjs

v2.9.2

This bugfix release fixes a potential internal data leak in SSR environments, improves handling of headers in fetchBaseQuery, improves retry handling for unexpected errors and request aborts, and fixes a longstanding issue with prefetch leaving an unused subscription. We've also shipped a new graphqlRequestBaseQuery release with updated dependencies and better error handling.

Changelog

Internal Subscription Handling

We had a report that a Redux SSR app had internal subscription data showing up across different requests. After investigation, this was a bug introduced by the recent RTKQ perf optimizations, where the internal subscription fields were hoisted outside of the middleware setup and into createApi itself. This meant they existed outside of the per-store-instance lifecycle. We've reworked the logic to ensure the data is per-store again. We also fixed another issue that miscalculated when there was an active request while checking for cache entry cleanup.

Note that no actual app data was leaked in this case, just the internal subscription IDs that RTKQ uses in its own middleware to track the existence of subscriptions per cache entry.

fetchBaseQuery Headers

We've updated fetchBaseQuery to avoid setting content-type in cases where a non-JSONifiable value like FormData is being passed as the request body, so that the browser can set that content type itself. It also now sets the accept header based on the selected responseHandler (JSON or text).

retry Behavior and Cleanup

The retry util now respects the maxRetries option when catching unknown errors in addition to the existing known errors logic. It also now checks the request's AbortSignal and will stop retrying if aborted.

In conjunction with that, dispatching resetApiState will now abort all in-flight requests.

The prefetch util and usePrefetch hook had a long-standing issue where they would create a subscription for a cache entry, but there was no way to clean up that subscription. This meant that the cache entry was effectively permanent. They now initiate the request without adding a subscription. This will fetch the cache entry and leave it in the store for the keepUnusedDataFor period as intended, giving your app time to actually subscribe to the value (such as prefetching the cache entry in a route handler, and then subscribing in a component).

graphqlRequestBaseQuery

We've published @rtk-query/graphql-request-base-query v2.3.2, which updates the graphql-request dep to ^7. We also fixed an issue where the error handling rethrew unknown errors - it now returns {error} as a base query is supposed to.

What's Changed

Full Changelog: https://github.com/reduxjs/redux-toolkit/compare/v2.9.1...v2.9.2

2025-10-17 10:53:02
redux-toolkit
reduxjs

v2.9.1

This bugfix release fixes how sorted entity adapters handle duplicate IDs, tweaks the TS types for RTKQ query state cache entries to improve how the data field is handled, and adds better cleanup for long-running listener middleware effects.

What's Changed

Full Changelog: https://github.com/reduxjs/redux-toolkit/compare/v2.9.0...v2.9.1

2025-10-17 09:49:28
redux-toolkit
reduxjs

@rtk-query/codegen-openapi@2.1.0

This feature release adds new RTK Query codegen config options for useUnknown and esmExtensions, update the hook name generation to make use of operationNameSuffix if available, fixes an issue with falsy query params, adds the CLI binary to the list of exports, and updates the swagger-parser dep to give support for OpenAPI v3.0.4

Changelog

New Config Options

We've added two new config options:

  • useUnknown: if enabled, tells the underlying oazapfts library to use unknown as a fallback type instead of any (per https://github.com/oazapfts/oazapfts/issues/676 )
  • esmExtensions: if enabled, import statements will use the appropriate compiled file extension explicitly (such as import { api } from 'emptyApi.mjs')

Fixes

Fixed an issue where encodeQueryParams: true would omit falsy values like 0 entirely, instead of encoding them as someValue=.

Hook names now include the operationNameSuffix if specified for that endpoint.

Other Updates

The package CLI is now properly listed in the package.json exports.

The @apidevtools/swagger-parser dependency was updated, which should enable support for OpenAPI v3.0.4 format files.

What's Changed

Full Changelog: https://github.com/reduxjs/redux-toolkit/compare/@rtk-query/codegen-openapi@2.0.0...@rtk-query/codegen-openapi@2.1.0