Rethinking Reusable Components: When Duplication Outweighs Premature Abstraction

The Pitfalls of Premature Reusability

The common advice in frontend development is to create reusable components by abstracting similar screens. However, this article posits that sometimes it is better to delay this process. Creating an abstracted component incurs higher coding and coordination costs, and a wrong abstraction can be more expensive to undo than simply removing duplicated code.

A Case Study: One Component, Three Workflows

The author recounts an experience with three distinct workflows: item approval, item change, and item movement. Despite their interfaces appearing similar (item list, select, confirm, results), the underlying processes had critical differences. These included how they handled partial failures, specific requirements, and auditing needs. For instance, item relocation involved another system that could reject requests, a factor not present in the other workflows.

The Cost of Over-Generalization

Initially, the decision was made to create a single component due to the perceived similarities. This led to a component that grew in complexity, incorporating numerous flags and modes (e.g., 'mode', 'variant', 'showDetails', 'requireReason', 'onSpecialCase') to accommodate the distinct behaviors of each workflow. This approach resulted in a component with multiple submission paths and error shapes, indicating that the initial abstraction was flawed because it did not account for the deeper functional divergences.