The Dilemma of Growing Common Components Healthily

Common components boost reusability at first, but over time their scope of responsibility and maintenance cost grow together. Like the already-implemented StaticLabelTextArea, something may appear naturally suited for commonization on the surface, but in reality it depends on a component scheduled for deprecation and has few usage points, so the benefits of commonization aren't always significant.

Old common components keep absorbing requirements and gradually become bloated. For example, CoverageSelectCard started out as a UI for selecting insurance products, but ended up taking on multiple roles simultaneously—opening/closing bottom sheets, manipulating iOS body height, drag interactions, and controlling animations and delays. Ultimately, the important question shifts from "can this be made common" to "when and by what criteria should this be separated to make maintenance easier."

Conversely, for small, independent components like DelayRender, keeping them common can be reasonable. However, if actual usage points are few and the scale can be sufficiently handled within the app itself, the justification for keeping it as a common component weakens. This is why it becomes important to share criteria within the team—such as how many repetitions should be considered "common," and how to weigh actual usage frequency against management cost.

A template should be viewed not merely as a way of bundling several components together, but as a structure that locks in specific decisions as code. When the same combination repeats and the ownership of that combination is clear, it's fine to combine them—but if exceptions keep arising screen by screen, or if the pattern hasn't been validated yet, it's better to leave things separated rather than solidify them into a template. In other words, a template is less a tool for reuse and more a set of decisions agreed not to be changed.

Over time, some common components stop being chosen, or reach a state where changing them creates too large a blast radius to touch in practice. At this point, deprecated isn't a declaration of failure—it's a choice made to reduce cost. Amid design system maintenance and a team's redefinition of UI standards, it also naturally becomes necessary to redefine the role of existing common components or propose replacement components.

As an alternative, the Headless component approach is proposed. In this approach, only core behaviors—state management, interaction logic, accessibility—are provided in common, while style and visual presentation are determined by the usage site. With a structure that keeps stability and accessibility common while allowing flexibility in design, it becomes easier to strike a better balance between maintainability and extensibility suited to the service's characteristics.

Ultimately, the way to grow common components healthily isn't about making more of them or merging more of them together. It's closer to asking, before building: whether existing combinations can already solve the problem, whether it's fine to say "this isn't common right now," and whether the structure allows moving it later—and continuing to ask, even during use, whether keeping it common is still the right call.