A Short, Practical Guide to Component Naming
by Angela Fisher, Front-end Developer
1. Name the Responsibility
The best name explains why a component exists, not merely what it looks like. CheckoutSummary tells a future reader more than Card, while PrimaryButton says less than SubmitOrderButton when the action is specific to one journey.
Start with the domain language the product team already uses. When design, engineering, and product share a vocabulary, the interface and its implementation are easier to reason about together.
2. Make Search Work for the Team
Names are part of a codebase’s navigation. A useful name should be distinctive enough to find and predictable enough that someone can guess it before searching.
Use consistent pairs such as Dialog, DialogTrigger, and DialogContent for primitives. For product components, prefer the user concept—PlanComparison or AccountRecoveryForm—over the page or folder where it happens to live today.
3. Let Names Evolve
A component that becomes hard to name is often trying to do too much. Treat that friction as useful feedback: its responsibilities may need to be separated, or its place in the product model may no longer be clear.
Rename deliberately as the system changes, and make the change everywhere in one pass. Consistency matters more than discovering a perfect universal convention. The goal is a codebase that gives the next person a reliable mental model.
