Description
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.