search

artsy / react-redux-controller

Library for creating a controller layer to link React and Redux, on top of react-redux.
MIT License
97 stars 10 forks source link

Performance issues to be reckoned with #5

Open acjay opened 8 years ago

acjay commented 8 years ago

According to the react-redux README, the approach of using a single connect to listen to the store for the whole component tree is a potential performance landmine.

How bad is it, if the whole component tree is stateless? I don't know. We have a lot of features to add in the project this is being piloted in. We do know we're going to see the worst possible scenario because every component depends on the React context, which changes every time the state changes, which is probably every user- or service-initiated action. This won't lead to repaints, but it will lead to a lot of throwaway React work.

That said, all the information to optimize this is readily available, especially since all components are dumb and pure. We know, at build-time, all the possible child components of a component. We know, at build-time, all the data dependencies of a component, via propTypes and contextTypes. So we should be able to pretty easily derive reasonable shouldComponentUpdate implementations at places where we find optimization to be necessary.

How to use this information best, e.g. with the least amount of boilerplate, is the question.

svnlto commented 8 years ago

So we should be able to pretty easily derive reasonable shouldComponentUpdate implementations at places where we find optimization to be necessary.

If your state tree is based of, let's say something like immutable + selectors, performance should not really be an issue.

Please correct me if I'm wrong.

acjay commented 8 years ago

Thanks for chiming in, Sven! :)

I'm not too concerned about the performance of selector computation. We'll profile it as we go, but I think it's going to account for a very tiny chunk of time on each dispatch, especially with reselect for memoization.

The bigger problem is that, without further optimization, each dispatch cycle that results in a change to any selector will result in a full VDOM re-render. This definitely will reduce the maximum performance of React+Redux. What I'm not sure of is at what point that will actually degrade user experience, but presumably we'll hit it first on mobile.

With some work on tracking the component dependencies, I think we can get it to the point where we are pruning the subtrees of components that are insensitive to selectors that have changed. That would seem to me to be roughly the same as the situation where props are passed down from the root.