NewYour coding agent can read the release notes before it upgrades.Set up the MCP server →
npm · #1523 most downloaded on npm
Official React bindings for Redux
Last release 4 months ago
15 May 2026
Ships unpredictably
gaps range from 2 weeks to 1.4 years
Nearly every release is documented
notes for 60 of the last 60 stable releases
7 versions withdrawn
withdrawn after publishing
11 years old
142 releases · first in 2015
Initial release, but we missed some updated docs. Ignore this 😄
Initial release, but we missed some updated docs. Ignore this 😄
Nothing published for this version
This release should be public-API-compatible with version 6. The only public breaking change is the update of our React peer dependency from 16.4 to 1…
React-Redux version 7 resolves the performance issues that were reported with version 6, and lays the groundwork for us to design and ship a public useRedux()-type Hooks API in a later 7.x release.
The major change for this release is that connect is now implemented using Hooks internally. Because of this, we now require a minimum React version of 16.8.4 or higher.
This release has undergone extensive performance benchmarking, and we're confident that it's the fastest version of React-Redux yet! We've also expanded our test suite to cover a number of additional use cases and scenarios. Now we need the community to help us make sure it's good to go. Please test this out in your applications and give us feedback in PR #1209. We're especially interested in info on any performance or feature regressions, but we also would appreciate hearing "tried it in our app, and it works great!" feedback as well.
npm install react-redux@next
For discussion on the reasons for the major version change and the development process, see:
issue #1177 - React-Redux Roadmap: v6, Context, Subscriptions, and Hooks.
This release should be public-API-compatible with version 6. The only public breaking change is the update of our React peer dependency from 16.4 to 16.8.4.
In v6, we switched from individual components subscribing to the store, to having <Provider> subscribe and components read the store state from React's Context API. This worked, but unfortunately the Context API isn't as optimized for frequent updates as we'd hoped, and our usage patterns led to some folks reporting performance issues in some scenarios.
In v7, we've switched back to using direct subscriptions internally, which should improve performance considerably.
(This does result in some changes that are visible to user-facing code, in that updates dispatched in React lifecycle methods are immediately reflected in later component updates. Examples of this include components dispatching while mounting in an SSR environment. This was the behavior through v5, and is not considered part of our public API.)
React has an unstable_batchedUpdates API that it uses to group together multiple updates from the same event loop tick. The React team encouraged us to use this, and we've updated our internal Redux subscription handling to leverage this API. This should also help improve performance, by cutting down on the number of distinct renders caused by a Redux store update.
connect Rewritten with HooksWe've reimplemented our connect wrapper component to use hooks internally. While it may not be visible to you, it's nice to know we can take advantage of the latest React goodies!
store as a PropWe've brought back the ability to pass a store as a prop directly to connected components. This was removed in version 6 due to internal implementation changes (components no longer subscribed to the store directly). Some users expressed concerns that working with context in unit tests was not sufficient. Since our components use direct subscriptions again, we've reimplemented this option, and that should resolve those concerns.
batch API for Batched React UpdatesReact's unstable_batchedUpdate() API allows any React updates in an event loop tick to be batched together into a single render pass. React already uses this internally for its own event handler callbacks. This API is actually part of the renderer packages like ReactDOM and React Native, not the React core itself.
Since React-Redux needs to work in both ReactDOM and React Native environments, we've taken care of importing this API from the correct renderer at build time for our own use. We also now re-export this function publicly ourselves, renamed to batch(). You can use it to ensure that multiple actions dispatched outside of React only result in a single render update, like this:
import { batch } from "react-redux";
function myThunk() {
return (dispatch, getState) => {
// should only result in one combined re-render, not two
batch(() => {
dispatch(increment());
dispatch(increment());
})
}
}
If you are using an alternative React renderer, like the Ink CLI renderer, that method isn't available for us to import. In that case, you will need to change your code to import from the new react-redux/es/alternate-renderers entry point instead. (Use react-redux/lib/alternate-renderers for the CJS version). That entry point exports a no-op version of batch() that just executes the callback immediately, and does not provide React batching.
In that situation, you may want to consider aliasing react-redux to one of those alternate entry points in your build tool for the best compatibility, especially if you're using any other libraries that depend on React-Redux.
Thanks to:
One column per quarter.
This is a minor release with support for react-hot-loader and a few small bug fixes for edge cases.
This is a minor release with support for react-hot-loader and a few small bug fixes for edge cases.
While you're here, please stop by #1177 to see our roadmap for the next versions of React Redux. We are aware that performance is not so hot in 6.0. Short version: We put too much traffic on React's context API, which isn't really designed for high levels of reads and writes. We're looking to reduce that load and get performance back on track in a minor release, so there won't be backwards compatibility concerns. We have a new extensive benchmark suite to keep us on track and ensure we're not regressing on speed in the future.
And yes, we know about Hooks. Check out #1179.
context prop really contains a React context (#1134 by @casdevs)🎉 This is our first big release supporting the new Context API added in React 16.4!
🎉 This is our first big release supporting the new Context API added in React 16.4!
As such, we now require React 16.4 or higher. Make sure to update your version when updating to this release.
This work has been mostly lead by @cellog and @markerikson, with special guest appearances by yours truly and a whole cast of helpful reviewers.
Note: If you'd like to know more about the changes in v6, and how the implementation has changed over time, see Mark's post Idiomatic Redux: The History and Implementation of React-Redux.
The withRef option to connect has been replaced with forwardRef. If {forwardRef : true} has been passed to connect, adding a ref to the connected wrapper component will actually return the instance of the wrapped component.
Passing store as a prop to a connected component is no longer supported. Instead, you may pass a custom context={MyContext} prop to both <Provider> and <ConnectedComponent>. You may also pass {context : MyContext} as an option to connect.
Any library that attempts to access the store instance out of legacy context will break, because we now put the store state into a <Context.Provider> instead. Examples of this include connected-react-router and react-redux-subspace. (The current implementation does also put the store itself into that same context. While accessing the store in context is not part of our public API, we will still try to make it possible for other libraries to access it, with the understanding that this could break at any time.)
Also, there is a behavior change around dispatching actions in constructors / componentWillMount. Previously, dispatching in a parent component's constructor would cause its children to immediately use the updated state as they mounted, because each component read from the store individually. In version 6, all components read the same current store state value from context, which means the tree will be consistent and not have "tearing". This is an improvement overall, but there may be applications that relied on the existing behavior.
null as a valid plain object prototype in isPlainObject() (#1075 by @rgrove)Treat null as a valid plain object prototype in isPlainObject() (#1075 by @rgrove)
null as a valid plain object prototype in isPlainObject() (#1075 by @rgrove)Just a small fix to relax the React peer dependency back to 16.4+.
Just a small fix to relax the React peer dependency back to 16.4+.
🎉 This is our first big release supporting the new React Context API! No more blocked updates!
🎉 This is our first big release supporting the new React Context API! No more blocked updates!
As such, we now require React 16.4 or higher. Make sure to update your version when updating to this release.
This work has been mostly lead by @cellog and @markerikson, with special guest appearances by yours truly and a whole cast of helpful reviewers. While we've had a lot of eyes on this refactor, we need more! Please test this out in your applications and let us know if there are big performance or feature regressions.
npm install react-redux@next
Note: 6.0.0-beta.2 is now on npm. This fixes an incorrect peer dependency for React 16.6 in beta.1.
Known major breaking changes:
withRef option to connect has been replaced with forwardRef. If {forwardRef : true} has been passed to connect, adding a ref to the connected wrapper component will actually return the instance of the wrapped component. (Known issue: Redux Form currently relies on withRef.)store as a prop to a connected component is no longer supported. Instead, you may pass a custom context={MyContext} prop to both <Provider> and <ConnectedComponent>. You may also pass {context : MyContext} as an option to connect.Any library that attempts to access the store instance out of legacy context will break, because we now put the store state into a <Context.Provider> instead. Examples of this include connected-react-router and react-redux-subspace. (The current implementation does also put the store itself into that same context. While accessing the store in context is not part of our public API, we will still try to make it possible for other libraries to access it, with the understanding that this could break at any time.)
Also, there is a behavior change around dispatching actions in constructors / componentWillMount. Previously, dispatching in a parent component's constructor would cause its children to immediately use the updated state as they mounted, because each component read from the store individually. In version 6, all components read the same current store state value from context, which means the tree will be consistent and not have "tearing". This is an improvement overall, but there may be applications that relied on the existing behavior.
Other than those issues, this should be API-compatible with the existing version 5.x line.
Nothing published for this version
Nothing published for this version
Nothing published for this version
Bump up hoist-non-react-statics version (@timdorr)
Upgrade hoist-non-react-statics to deal with contextType (by @timdorr)
null as a valid plain object prototype in isPlainObject() (#1075 by @rgrove)The biggest fix is for connect() being used with React's newer forwardRef, memo, and lazy APIs.
The biggest fix is for connect() being used with React's newer forwardRef, memo, and lazy APIs.
We also have begun a complete rewrite of our docs for React Redux. Check them out! Many thanks to those who contributed: @markerikson, @sveinpg, @wgao19, @BTMPL, @pyliaorachel, @dagstuan, @Kerumen, and @carloluis (sorry if I forgot someone!). Docs are a great way to get started contributing to open source, so open a PR today! Check #1001 to see what else needs to be done.
We're also looking at overhauling Redux's documentation. Check out reduxjs/redux#2590 for the latest there.
This is a test release to try out some changes in relation with React 16.3's new StrictMode. ~Please try it out in your projects and see if it breaks
This is a test release to try out some changes in relation with React 16.3's new StrictMode. ~Please try it out in your projects and see if it breaks anything!~
Narrator: It did.
It turned out to be very broken, and should not be used.
We are currently working on React-Redux version 6.0, which will switch to using createContext internally. See #950 for our development roadmap, and #995 and #1000 for the two "competing" work-in-progress PRs (available on NPM as tags next-995 and next-1000). Please try those out instead, and give us feedback in the PR threads.
Changelog for historical reference
- Remove subkey arg (#945 by @theJian)
- Simplify object check and eliminate lodash dependency (#936 by @matthargett)
- Remove usages of async-unsafe lifecycle methods (#919 by @Hypnosphi)
Update hoist-non-react-statics to support getDerivedStateFromProps
getDerivedStateFromPropsmethodName in error message (#852 by @pwnn)Persist child listeners through hot reload (#715 by @dsgkirkby)
Upgrade prop-types to fix UMD warnings (Fixes #696)
<Provider> using a specific store key (#695 by @tleunen)Fix deprecation warnings with React 15.5.0 (#663 by @Calyhre)
Fix subscription bug when a new store is passed as a prop (fixes HMR). (#589 by @jimbolla)
Fix storeSubscription context object getting lost (#579 by @jimbolla)
Use the correct filename for the UMD build. It is now properly published as dist/react-redux.js and dist/react-redux.min.js.
dist/react-redux.js and dist/react-redux.min.js.This release is brought to you by contributions from the following people: @jimbolla, @vhmth, @btd, @roncohen, @ynonp, and @appden. In addition, there
This release is brought to you by contributions from the following people: @jimbolla, @vhmth, @btd, @roncohen, @ynonp, and @appden. In addition, there were many non-code contributions in discussions on issues and testing the alpha, beta, and rc versions by many other folks (too many to list!). Thank you to everyone who made this a very positive, inclusive, well-critiqued, community-driven release!
connect()connectAdvanced() APIVersion 5.0 maintains API compatibility with v4.x but due to major internal changes and potential behavior differences across nearly all API surfaces, semver dictates a major version bump. Also, it's good marketing! 💰 Store state change notifications sent to components are now guaranteed to occur top-down, so if your code may behave differently if it relied on notifications happening out of order.
Internally, the code for connect has been rewritten from the ground-up to be more modular, with the intention of greater maintainability and extensibility. This has also led to some new features and performance improvements.
Significant performance gains were achieved by avoiding extra calls to setState() and render() by ensuring the order of change notifications to occur top-down, matching React's natural flow. Performance tests and benchmarks are discussed in #416.
Some bugs/issues are resolved, related to performance loss and also impure components not re-rendering.
The behavior of connect() is now more customizable, by passing additional properties in the options arg. These will be described in the API docs.
The new implementation of connect() splits its behavior such that it is now a wrapper around a more-generalized connectAdvanced(). This connectAdvanced() method can be called directly if you have extreme performance needs or want to craft an API different than that of connect(). This will be described in the API docs.
We're looking at removing the shouldComponentUpdate optimization. Since this version is much more performant on its own, that isn't needed. This will fix long-standing problems with other libraries that use React's context API. There are workarounds, but things should work without either library authors having to bend over backwards or React having to make API changes.
We will accept bugfixes on the 4.x branch (the 3.x branch will be going away; but the tags to 3.x versions will remain!), but new features should be built against the next branch. We love PRs, so keep them coming!
``` sh npm install --save react-redux@next
npm install --save react-redux@next
# or
yarn add react-redux@next
Sorry about the flip-flopping, but we've removed the previous compatibility option. Another way of working around the issue was discovered that doesn't need configuration and has been implemented for this final release candidate. We should be ready to release a 5.0.0 final version tomorrow.
``` sh npm install --save react-redux@next
npm install --save react-redux@next
# or
yarn add react-redux@next
See the 5.0.0-beta.2 release notes if you're new to the 5.0 versions.
The big change for this version is a workaround for a cursor position bug in controlled input fields in React 15 or lower. See #525 for the gory details. There is a workaround in place that defaults to enabled, but will slightly reduce some of the performance gains of 5.0 (it is still faster, just not as fast). The underlying bug will be fixed in React 16 and we will default to disabling our workaround in the next release (scheduled for 5.1.0).
If you have no connected/controlled form inputs in your application, you can turn it off for all connected components like so:
// Before you ReactDOM.render()
import { connect } from 'react-redux'
connect.setDefaultReact15CompatibilityMode(false)
You can also pass a option to connect():
connect(mapStateToProps, mapDispatchToProps, mergeProps, { react15CompatibilityMode: false })
That's it! We should be pushing out a final release this weekend.
Remove Warn on Duplicate Props feature. DX needs improvement.
This is a massive rewrite of React Redux, done mainly by @jimbolla (see #416). There actually will likely be no changes needed to your applications an
This is a massive rewrite of React Redux, done mainly by @jimbolla (see #416). There actually will likely be no changes needed to your applications and we encourage you to try this version out in your applications without modification.
connect()connectAdvanced() APIVersion 5.0 maintains API compatibility with v4.x but due to major internal changes and potential behavior differences across nearly all API surfaces, semver dictates a major version bump. Also, it looks cooler! Store state change notifications sent to components are now guaranteed to occur top-down, so if your code may behave differently if it relied on notifications happening out of order.
Internally, the code for connect has been rewritten from the ground-up to be more modular, with the intention of greater maintainability and extensibility. This has also led to some new features and performance improvements.
Significant performance gains were achieved by avoiding extra calls to setState() and render() by ensuring the order of change notifications to occur top-down, matching React's natural flow. Performance tests and benchmarks are discussed in #416.
Some bugs/issues are resolved, related to performance loss and also impure components not re-rendering.
The behavior of connect() is now more customizable, by passing additional properties in the options arg. These will be described in the API docs.
The new implementation of connect() splits its behavior such that it is now a wrapper around a more-generalized connectAdvanced(). This connectAdvanced() method can be called directly if you have extreme performance needs or want to craft an API different than that of connect(). This will be described in the API docs.
We're looking at removing the shouldComponentUpdate optimization. Since this version is much more performant on its own, that isn't needed. This will fix long-standing problems with other libraries that use React's context API. There are workarounds, but things should work without either library authors having to bend over backwards or React having to make API changes.
We will accept bugfixes on the 4.x branch (which will be created after this version goes final), but new features should be built against the next branch. We love PRs, so keep them coming!
Nothing published for this version
Nothing published for this version
Update hoist-non-react-statics to 3.x
Update hoist-non-react-statics to 2.x
Fix deprecation warnings with React 15.5.0 (#666 🤘 by @Calyhre)
Allow React 16 as peerDependency (#660 by @gaearon)
Update React peer dependency to allow React 15.4.0 RC
Fixes a regression introduced in 4.4.4 where cleaning up the state in parent’s componentWillUnmount caused an error in child’s mapStateToProps (#351,
componentWillUnmount caused an error in child’s mapStateToProps (#351, ea53d6fb076359a864a1d543568d951d4b3eab3d)Bail out of calling setState() when mapStateToProps() doesn’t care about ownProps (#348, #300)
setState() when mapStateToProps() doesn’t care about ownProps (#348, #300)State shape warning now has a more descriptive message (#335, #309)
Custom mergeProps now works correctly with components that have pure: false (#337, #338)
mergeProps now works correctly with components that have pure: false (#337, #338)React v15 is now allowed as a peer dependency (#317, #319)
Removes the broken jsnext:main. It is supposed to point to the ES module build but we mistakingly pointed it to the src, so it never worked for anyone
jsnext:main. It is supposed to point to the ES module build but we mistakingly pointed it to the src, so it never worked for anyone anyway. For now, we don’t provide an ES module build in React Redux, so if you use Rollup, you need to use the CommonJS plugin for it. Realistically, it doesn’t make a big difference because React Redux assumes you use React anyway (which uses CommonJS), and it also doesn’t benefit from tree shaking because there are only two exports (connect and <Provider>) and you will need both pretty much any time.This is a minor bump because we couldn’t break anybody with this (it was broken before), but it seems to deserve more than a patch bump as it’s a change in the build configuration.
Adds per-instance memoization API. If your mapStateToProps or mapDispatchToProps returns a function, _that_ function will be used instead for the give
mapStateToProps or mapDispatchToProps returns a function, that function will be used instead for the given component instance. Most apps never need this, but it can be handy for custom memoization logic in apps with large component trees. It can bring significant performance improvements when used together with Reselect. (#279, 7ee928b23ea0ad15e22b51d7d4aff5eb1a0f95b5, #179)Bump Lodash to 4.2.0 (rackt/redux#1346, rackt/redux#1349)
isPlainObject that we use internally is now outsourced to Lodash 4.1 (rackt/redux#1339). Note that this does not mean we depend on Lodash itself. We o
isPlainObject that we use internally is now outsourced to Lodash 4.1 (rackt/redux#1339). Note that this does not mean we depend on Lodash itself. We only use a tiny module from it. We also use the same module in Redux >= 3.2.0.Don't depend on console or console.error
console or console.error (https://github.com/rackt/redux/issues/1311, https://github.com/rackt/react-redux/commit/208efae97b59c39930533c6b3825a23f6f3d4b33)Adds loose-envify as a dependency to fix builds for Browserify users. (#1304 & #1306)
loose-envify as a dependency to fix builds for Browserify users. (#1304 & #1306)For Browserify users, Redux should now be properly envified without extra configuration
- Fixes a regression on IE8.
Avoids unnecessary recalculation of props for components that don't specify mapStateToProps
mapStateToProps (https://github.com/rackt/react-redux/commit/6c504b966839be0e739d5a566c8fb844c27a6c44#commitcomment-15145082, https://github.com/rackt/react-redux/commit/04693ca0cabe021b27b62eb9240b51459ffe8c32)Avoids use of Object.defineProperty() to prevent errors in IE8
Object.defineProperty() to prevent errors in IE8 (https://github.com/rackt/react-redux/issues/227)Fixes a bug that caused the props of connected components to not updated during a hot update with something like React Hot Loader. Internally, it invo
shouldComponentUpdate() into more appropriate places such as componentWillReceiveProps(), handleChange(), and render(). (https://github.com/rackt/react-redux/issues/224, https://github.com/rackt/react-redux/pull/225)Fixes a bug that caused mapStateToProps to be called twice instead of just once before the component is mounted.
mapStateToProps to be called twice instead of just once before the component is mounted. (https://github.com/rackt/react-redux/pull/196)Removes .babelrc in the compiled package because it is irrelevant (we ship ES5 code) and breaks React Native 0.16 and some consumers who use Babel 6 f
.babelrc in the compiled package because it is irrelevant (we ship ES5 code) and breaks React Native 0.16 and some consumers who use Babel 6 forgetting to exclude node_modules from transformations. (https://github.com/rackt/react-redux/pull/213, https://github.com/rackt/redux/issues/1033, https://github.com/rackt/redux/issues/1039, https://github.com/rackt/redux/issues/1127)If you need 0.13 support, keep using 3.x. In addition, React has now been promoted to be a peer dependency because you’ll use the same react package f
If you need 0.13 support, keep using 3.x. In addition, React has now been promoted to be a peer dependency because you’ll use the same react package for web and native.
react-redux/native entry point has been removedTrack this React Native issue and wait until RN works on top of React 0.14. Then React Redux 4.x should “just work” in React Native. Until then, you need to keep using 3.x with React Native.
<Provider> no longer accepts a function childThis resolves a ton of router-related issues and also helps beginners understand what's going on.
React.render(
<Provider>
{() => <App />}
</Provider>,
rootEl
);
ReactDOM.render(
<Provider>
<App />
</Provider>,
rootEl
);
connect() no longer provides a ref to the wrapped component by default. You need to specify withRef: true in the options as the fourth argument to connect() to get the old behavior. getWrappedInstance() will throw unless you do that.
This fixes https://github.com/rackt/react-redux/issues/141.
class MyComponent extends Component { ... }
MyComponent = connect(mapStateToProps)(MyComponent);
// later
let instance = React.render(<MyComponent />, targetEl);
console.log(instance.getWrappedInstance());
class MyComponent extends Component { ... }
MyComponent = connect(mapStateToProps, null, null, { withRef: true })(MyComponent);
// later
let instance = ReactDOM.render(<MyComponent />, targetEl);
console.log(instance.getWrappedInstance());
(Note: this is a 3.x release. Unless you’re using React Native, you should use 4.x instead.)
(Note: this is a 3.x release. Unless you’re using React Native, you should use 4.x instead.)
react-redux/native in 3.1.1 (https://github.com/rackt/react-redux/issues/216)(Note: this is a 3.x release. Unless you’re using React Native, you should use 4.x instead.)
(Note: this is a 3.x release. Unless you’re using React Native, you should use 4.x instead.)
.babelrc in the compiled package because it is irrelevant (we ship ES5 code) and breaks React Native 0.16 and some consumers who use Babel 6 forgetting to exclude node_modules from transformations. (https://github.com/rackt/react-redux/pull/213, https://github.com/rackt/redux/issues/1033, https://github.com/rackt/redux/issues/1039, https://github.com/rackt/redux/issues/1127)Static methods are now hoisted and available on the connected component. The exact semantics are provided by hoist-non-react-statics.
Object.defineProperty for IE8 support in the CommonJS build. We won't pledge to support IE8 forever but this was a low-hanging fruit. Note that UMD build still may have problems with IE8 because it uses screw_ie8 option—if you really care, use CommonJS build and choose Uglify options yourself. (https://github.com/rackt/react-redux/pull/135, https://github.com/rackt/react-redux/issues/133)Fixes a regression introduced in 3.0.0 that caused component with { pure: false } to not get updated (#118, #122)
{ pure: false } to not get updated (#118, #122)This release is identical to 3.0.0-alpha. If you’re already using it, you don’t need to change anything.
This release is identical to 3.0.0-alpha. If you’re already using it, you don’t need to change anything.
Now the map functions (mapStateToProps, mapDispatchToProps and mergeProps) are not called until React starts to render the connect()ed components. Previously the map functions where called immediately when store changed which could cause weird edge case bugs when the ownProps parameter was a derivative of the state. The state from which it was derivative of was a different version than what was passed as the stateparameter. In some cases when using nested connect()ed components the states can be incompatible with each other and cause very confusing bugs in user code.
Unfortunately the state stays consistent only when store dispatches are called in batches ie. from DOM handlers or manually from ReactDOM.unstable_batchedUpdates(fn). Luckily redux-batched-updates middleware can be used to force batching for all dispatches. Also React plans to move on batching by default so this will become obsolete in future.
If you're interested in the details, feel free to check out:
Now the map functions (mapStateToProps, mapDispatchToProps and mergeProps) are not called until React starts to render the connect()ed components. Pre
Now the map functions (mapStateToProps, mapDispatchToProps and mergeProps) are not called until React starts to render the connect()ed components. Previously the map functions where called immediately when store changed which could cause weird edge case bugs when the ownProps parameter was a derivative of the state. The state from which it was derivative of was a different version than what was passed as the stateparameter. In some cases the states can be incompatible with each other and cause very confusing bugs in user code.
Unfortunately the states stay consistent only when store dispatches are called in batches ie. from DOM handlers or manually from ReactDOM.unstable_batchedUpdates(fn). Luckily redux-batched-updates middleware can be used to force batching for all dispatches.
If you're interested in the details, feel free to check out:
Declare compatibility with Redux 3.x in peerDependencies
peerDependenciesYour coding agent can read these notes before it upgrades. Set up the MCP server →