Pure Components FTW
I really like this division of components, but I prefer the original version where Presentational Components (‘PC’) were not allowed to contain Container Components (‘CC’).
In the original version PC’s had a clear dependency on the props and internal state only. (Sometimes called “pure”, not to be confused with pure functions) Now a PC might indirectly depend on e.g. the global state through the children, if they are CC.
With this change we ruin several of the stated “Benefits of This Approach”.
For example we can’t put our PC on a test single page with some fake data through the props to tweak the UI. We are back in a situation where we need to create a mock environment for the component. This is bad. Roman Pominov in this thread have a valid question on this.
Also the new definition of PC limits composability and re-use of PC-components. The new version makes it much harder to understand the code. The original PC, is much easier to reason about than something with hard coupled dependencies. Weather a PC has an internal state or not is an implementation detail and should be OK. But I do not understand how dependency on e.g. global state or a Redux store can
be considered an “implementation detail”. To me it’s a completely different animal!
In the ideal world everything is easy: we have pure PC’s and CC’s, where the latter only wire things up with connect. But in reality life is not so easy.
It is clear that we need to make a compromise somewhere: we do not want the UI to be composed by components where we need to pass props around the whole way from top to bottom. This way parents and children gets to coupled. So where do we compromise? IMHO not with the PC’s. The best is to keep them “pure”. When there are to many props passed from parents to children we may consider leak some presentational code into the CC instead.
But if the presentational components aren’t pure, what’s the point of introducing them at all?