Unpack the idea of "Smart and Dumb" components # (References…
Unpack the idea of "Smart and Dumb" components
Advantages of dropping the smart/dumb pattern
No need to establish component naming conventions or otherwise distinguish a components TYPE
Easy to test components in isolation from any transformations that need to happen to their values
Export raw component separately from final component which wraps it in propsMappers that preprocess the props it receives
No need to write tests with mocks and spies or tests that mutate and check internal component state
noisy inline logic can be avoided and leave fewer code paths per component by allowing a step to compute ideal values at each boundary
This allows composition instead of inheritance for similar but different components, rather than
more difficult to understand / debug / test by nature
Silly Inheritance example
Silly composition example
redux-little-router companion articles
Smart and dumb components can subtract from the simplicity of redux
Everything changes when you use a state container like Redux. If you treat your Redux application as a pure function that accepts state and returns a UI, every component is a dumb component.
What’s the point of a container component if Redux controls all of your state?
Like heat, your state rises to the top, and your state container absorbs it and manages its logic.
In fact, a container component violates the Single Responsibility Principle when it assumes responsibilities of the state container. It couples your view layer to your state layer.