A function with a contract
The props type is the interface. Almost every component that is unpleasant to use has a props type that gave away the game.
A component takes props and returns a description. Its props type is therefore a full statement of what it needs and, implicitly, what it is responsible for. A component whose props include both a userId and a fully loaded user object is telling you it has not decided whether it fetches. One with twelve optional props is telling you it is really four components.
The useful question is what varies. Props are the axes of variation you have chosen to support, and every one you add is a promise to keep it working in combination with all the others. Twelve booleans is four thousand combinations, of which you have looked at six.
Generated components fail here in a characteristic way: they accumulate props, because adding one is the smallest possible diff that satisfies a request. Nothing in a model’s incentives pushes towards splitting a component in two. That refactor is one you have to ask for explicitly, and knowing when to ask is the skill.
You should now be able to
- Read a props type as a statement about responsibility
- Spot a component that is doing two jobs
Loading…