Potential connect() optimization

As described in https://github.com/reactjs/redux/issues/1437#issuecomment-187763637, we can try introducing a separate code path for the fast case where neither state props nor dispatch props depend on the own props. In this case the problem from #99 seems irrelevant and we can do the fast check before calling setState().

I am not convinced that this is the best solution however. It basically forces computations to happen in the handleChange() hook which React has no control over. If in the future React learns to prioritize updates, it will not be able to schedule this work for later, but if we keep things as they are today, it will be able to do this just by postponing render().

[markerikson]

@matianfu , @davibe : I think your concerns are based on a misunderstanding of how the Connect wrapper component actually works. Note that there is a distinction between “the Connect wrapper component re-renders” and “the wrapped original component re-renders”.

The wrapper component does not actually call your mapStateToProps function as part of the shouldComponentUpdate logic. That call is deferred as long as possible, and actually only happens when the wrapper component re-renders. Per https://github.com/reactjs/react-redux/blob/master/src/components/connect.js#L248-L270 , during the wrapper rendering process, it re-runs your mapStateToProps, and checks to see if the merged props have actually changed since last time. If they have not (like, say, if an unrelated portion of the state store changed), then the Connect component directly returns the cached React element, and does not even tell your component to re-render.

So, what that means is that we DO want the Connect wrapper component to re-render if the store has changed, but that does NOT automatically mean that your own component will actually re-render as well. It just means that things MAY be different, and now the Connect component needs to do additional checking based on the store and mapStateToProps.

@davibe , you may need to do some additional looking at your components. Remember that Connect only does shallow equality checking by default - if you’re returning new instances in your mapStateToProps (such as using someArray.map()), those will always be seen as different and force a re-render of your component. It might help to use a debug tool that indicates why a component re-rendered, such as https://github.com/redsunsoft/react-render-visualizer , https://github.com/spredfast/react-transform-render-visualizer , or the “WhyDidYouUpdateMixin” listed at http://benchling.engineering/deep-dive-react-perf-debugging/ .

[gaearon]

This is now fixed in the common case in react-redux@4.4.4. For other cases, #348 contains a valuable tip.