v4.0.3

• 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 involved moving the memoized calculations from shouldComponentUpdate() into more appropriate places such as componentWillReceiveProps(), handleChange(), and render(). (#224, #225)

v4.0.2

• Fixes a bug that caused mapStateToProps to be called twice instead of just once before the component is mounted. (#196)

v4.0.1

• 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 forgetting to exclude node_modules from transformations. (#213, reduxjs/redux#1033, reduxjs/redux#1039, reduxjs/redux#1127)

v3.1.2

(Note: this is a 3.x release. Unless you’re using React Native, you should use 4.x instead.)

• Fixes an issue with missing react-redux/native in 3.1.1 (#216)

v3.1.1

(Note: this is a 3.x release. Unless you’re using React Native, you should use 4.x instead.)

• 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 forgetting to exclude node_modules from transformations. (#213, reduxjs/redux#1033, reduxjs/redux#1039, reduxjs/redux#1127)

v4.0.0

Breaking Changes

React 0.14 is now required and a peer dependency

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 removed

Track 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 child

This resolves a ton of router-related issues and also helps beginners understand what's going on.

Before

React.render(
  <Provider>
    {() => <App />}
  </Provider>,
  rootEl
);

After

ReactDOM.render(
  <Provider>
    <App />
  </Provider>,
  rootEl
);

Refs are now opt-in

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 #141.

Before

class MyComponent extends Component { ... }
MyComponent = connect(mapStateToProps)(MyComponent);

// later
let instance = React.render(<MyComponent />, targetEl);
console.log(instance.getWrappedInstance());

After

class MyComponent extends Component { ... }
MyComponent = connect(mapStateToProps, null, null, { withRef: true })(MyComponent);

// later
let instance = ReactDOM.render(<MyComponent />, targetEl);
console.log(instance.getWrappedInstance());

v3.1.0

• Static methods are now hoisted and available on the connected component. The exact semantics are provided by hoist-non-react-statics. (#53, #127)
• We removed usage of 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. (#135, #133)

v3.0.1

• Fixes a regression introduced in 3.0.0 that caused component with { pure: false } to not get updated (#118, #122)

v3.0.0

Breaking Changes Since 3.0.0-alpha

This release is identical to 3.0.0-alpha.
If you’re already using it, you don’t need to change anything.

Breaking Changes Since 2.x

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:

• A new test that was failing in 2.x, but is fixed in 3.0 beta
• The original issue
• The pull request attempting to fix it

v3.0.0-alpha

Breaking Change

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:

• A new test that was failing in 2.x, but is fixed in 3.0 beta
• The original issue
• The pull request attempting to fix it