Wasteful operations when mapStateToProps has 2 arguments, store triggers change event but props and state unchanged

As title suggests, when mapStateToProps is using both state and ownProps to select chunk of redux state, when store has some state updated, but the particular chunk of state which is returned by mapStateToProps has not been changed, connect produces wasteful render attempt. This is specifically bad in places when there is thousands of components wrapped with connect, or there is just couple of such components, store is updated quite frequently, but state of wrapped components is not changed. Issue is not reproduced when mapStateToProps is not using ownProps.

Performance degradation is seen in the task manager and in JS profiler, and becomes a visually noticeable problem on documents with complex DOM in Edge and Firefox. Measurements from React.addons.perf.printWasted show that on 10 seconds intervals the wasteful operations can take more than 1 second, the wasteful operations are happening inside Connect(Component).

Looking into profiling using Chrome profiler, a lot of time is spent inside ReactComponent.setState, looking into source code of connect.js, the problem is apparently in the handleChange.js, it does an unconditional this.setState when this.doStatePropsDependOnOwnProps is true. Perhaps an option to customize this behavior, e.g. by introducing support for custom comparer would be really nice.

Small sample project with reproduction has been set in https://github.com/vlan-saxo/react-redux-bug, use npm install, npm start and go to http://localhost:8080/webpack-dev-server/

[jimbolla]

I think this will be addressed by #407. I’m rewriting the Connect component to only fire setState() if the final props have changed. I’m seeing HUGE performance gains.

[PCreations]

Exactly, and I don’t know why either…