A Short Guide to Component Naming

1. Be Descriptive and Clear

A good component name tells you what the component does without needing to read its implementation. Future developers (including yourself) will thank you for choosing clarity over brevity.

Instead of cryptic abbreviations like "btn" or "md", use full descriptive names like "SubmitButton" or "ConfirmationModal". The few extra characters are worth the improved readability and maintainability.

Good component names should answer three questions: What does it do? What type of component is it? Where or how is it used? For example, "UserProfileCard" tells you it's a card component that displays user profile information.

2. Follow Consistent Patterns

Consistency in naming helps developers navigate your codebase efficiently. Establish patterns and stick to them across your project.

Common patterns include:

• Prefix specialized components: "AuthButton", "PaymentForm", "DashboardLayout"
• Use standard suffixes for component types: "List", "Item", "Container", "Wrapper"
• Be specific about context: "CheckoutStepIndicator" vs generic "StepIndicator"

When searching for components, consistent naming means developers can make educated guesses about what names might exist. If you have "ProductCard", they'll expect "ProductList" not "ProductGrid" or "ShowProducts".

3. Balance Specificity and Reusability

Component names should be specific enough to be clear but generic enough to be reusable. This is a balance that improves with experience.

For example, "PrimaryActionButton" is better than "SubmitCheckoutButton" if the component is used across multiple contexts. But if it truly has checkout-specific logic, the more specific name is appropriate.

Consider the component's scope:

• Highly reusable: Generic names like "Button", "Card", "Modal"
• Domain-specific: Names like "ProductCard", "UserAvatar", "CommentThread"
• Feature-specific: Names like "CheckoutSummary", "DashboardHeader"

The key is making sure the name accurately reflects the component's actual purpose and reusability. Don't make it more generic than it needs to be, and don't make it so specific that it can't be used where it makes sense.