Don’t Build the Reusable Component Yet

Frontend developers often receive advice to create reusable components. While this can lead to cleaner code, it also increases coding and coordination costs. Duplication can be removed, but a poor abstraction can be costly to undo. The author recalls a situation where they had to perform three similar actions: item approval, item change, and item movement.

They created one component to address the similarities, but soon realized that the processes differed in important aspects such as handling partial failures, requirements for each process, and auditing information. They suggest waiting until the pattern of changes is repeated three times with the same reason for changing before abstracting.

Instead, they recommend grabbing the code and letting each screen evolve independently. The author cites the "Rule of Three" from Refactoring by Martin Fowler and The Wrong Abstraction by Sandi Metz, which suggest refactoring when a piece of code is encountered for the third time. They also reference Kent C. Dodds' AHA programming, which advises against hasty abstractions.

The author provides three criteria for determining when an abstraction is justified: the shape is determined by something other than speculation on the future, there is a single reason why it should be changed, and it is a component or workflow. They suggest starting by inlining the common module back into each call site, copying the module’s code to each workflow, and removing unnecessary branches.

Once the code is stabilized, they recommend separating it according to the workflow rather than layout. The author asks for clarification on what piece of code people often debate and what special flag they use for that specific caller.