Why Premature Component Abstraction Harms Frontend Development
Avoid the trap of creating reusable components before patterns are fully understood.
1The Trap of Premature Abstraction
Developers are often encouraged to prioritize code reusability by abstracting similar UI elements into shared components. While this reduces initial line counts, it frequently introduces hidden costs. Prematurely combining distinct workflows into a single component creates complex dependencies, making future modifications difficult and requiring coordination across multiple teams for simple changes.
2Surface Similarities vs Structural Differences
Visual consistency often masks underlying functional differences between seemingly identical UI actions. For instance, approval, change, and movement workflows may share tables and pop-ups but serve different business logic. Treating these as a single component forces developers to add numerous flags, eventually creating a fragile, unmaintainable codebase that resists change.
3The Cost of Shared Logic
When unrelated workflows are forced into one component, any change to the confirmation procedure requires agreement from all involved stakeholders. This creates a bottleneck where simple updates necessitate testing across all modes and variants. The abstraction binds unrelated decisions together, turning simple feature requests into complex, multi-party architectural negotiations.
4Identifying True Code Duplication
Duplication is not merely about identical code blocks but about the reason for change. If a single product decision requires updating multiple locations simultaneously, those locations share a reason for change. However, if code looks identical but changes for different business reasons, they are coincidences, not true duplications requiring abstraction.
5Applying the Rule of Three
Industry experts like Don Roberts and Sandi Metz advocate for the rule of three: repeat code twice, but only refactor on the third occurrence. This strategy allows individual screens to evolve independently until a stable pattern emerges. Waiting prevents the creation of wrong abstractions that are significantly more expensive to undo.
6Evaluating Component Prop Lists
A simple smell test for abstraction quality is reading the component's props. If props describe rendering details like size or tone, the abstraction is likely healthy. If props describe the current situation or mode, such as 'isSpecial' or 'variant', you have likely combined several distinct things into one problematic, overly complex component.
7Retrograde Refactoring Strategy
If you have already built a problematic abstraction, inline the code back into each call site. Remove the branches that specific workflows do not use to simplify the logic. This retrograde approach makes each workflow independent and easy to understand, allowing teams to modify their specific features without seeking permission from others.
8Stabilizing Through Gradual Extraction
Once individual workflows are stabilized, identify truly common elements like date formatters or table styles. Extract only these small, shared pieces of code rather than entire workflows. By waiting for patterns to solidify, you ensure that your abstractions are based on actual requirements rather than speculative assumptions about future system behavior.