0Pricing
Design Systems & Component Libraries · Lesson

Naming Conventions for Components

Learn how clear, consistent naming of components and their props makes a component library discoverable, predictable, and maintainable.

Naming Conventions for Components is a free Design Systems & Component Libraries lesson on CoddyKit — lesson 4 of 4. You can read the complete lesson below for free — then practise it hands-on in the browser with a built-in code editor and a 24/7 AI tutor. It is part of the Design Systems & Component Libraries learning path, one of 4 lessons in the course, and your progress syncs across the web and the CoddyKit app.

Why Names Matter

The hardest problems in component libraries are not technical - they are naming. A poorly named component is hard to find, easy to misuse, and painful to rename later.

Good names act as documentation and reduce the questions teammates ask.

Be Descriptive, Not Clever

Name components by what they are or do, not by clever metaphors.

  • Good: UserAvatar, PrimaryButton
  • Avoid: Blob, Sparkle, Thingy

A new teammate should guess the purpose from the name alone.

Consistent Casing

Pick one casing rule and never deviate. The web convention:

  • Components: PascalCase (CardHeader)
  • Props: camelCase (isDisabled)
  • CSS classes: kebab-case (card-header)

Mixing casing styles erodes trust in the library.

Boolean Props

Boolean props read best with an is, has, or should prefix. They sound like questions and default to false.

The snippet below shows the pattern.

function describe(props) {
  return 'disabled=' + props.isDisabled + ', loading=' + props.isLoading;
}

console.log(describe({ isDisabled: true, isLoading: false }));

Prop Naming Patterns

Establish predictable prop names across all components:

  • variant for visual style (primary, ghost)
  • size for scale (sm, md, lg)
  • onChange, onClick for event handlers

If every component uses the same names, learning one teaches you all.

Avoid Implementation Details

Do not bake fragile details into names. BlueButton becomes a lie the moment the brand color changes.

Prefer intent-based names like PrimaryButton. The intent is stable even when the styling evolves.

Namespacing and Prefixes

Many systems prefix components to avoid clashes and signal origin: DsButton, AcmeCard.

This helps when consuming apps already have their own components. Choose a short prefix and apply it everywhere or nowhere - consistency over preference.

Compound Component Naming

Related parts should share a family name: Card, CardHeader, CardBody, CardFooter.

The shared prefix groups them in autocomplete and signals they belong together. This is far clearer than Card, Heading, Content.

Renaming Is Expensive

Once a component name ships, every consuming app depends on it. Renaming becomes a breaking change requiring deprecation cycles.

Invest time in the name up front. A 10-minute naming discussion saves months of migration pain.

Document the Rules

Write your naming conventions down in the contribution guide. New contributors should not have to reverse-engineer your patterns.

A short, enforced naming doc keeps the library coherent as more people contribute.

Names as a Contract

Ultimately, a component's name and prop names form a public API contract. Treat them with the same care as any API.

Predictable names let developers compose your library confidently without reading the source.

Quick Check

Test your naming instincts.

Recap

You learned naming conventions that keep a component library usable:

  • Be descriptive and intent-based, not clever or color-bound.
  • Use consistent casing and predictable prop names.
  • Group compound components with shared prefixes.
  • Document the rules and remember renaming is costly.

Good names are quiet documentation.

Frequently asked questions

Is the “Naming Conventions for Components” lesson free?

Yes — the full text of “Naming Conventions for Components” is free to read here on the web, and the Design Systems & Component Libraries course includes 4 lessons in total. To practise it interactively (a built-in code editor and a 24/7 AI tutor) and unlock the rest of the Design Systems & Component Libraries course, upgrade to CoddyKit PRO.

What will I learn in “Naming Conventions for Components”?

Learn how clear, consistent naming of components and their props makes a component library discoverable, predictable, and maintainable. You practise Design Systems & Component Libraries with hands-on code you run directly in the browser, and a 24/7 AI tutor answers your questions as you work through the lesson.

Do I need any experience to start Design Systems & Component Libraries?

No prior experience is required. Design Systems & Component Libraries on CoddyKit is structured for beginners through advanced learners; this is — lesson 4 of 4, so you can start here or from the beginning and move at your own pace.

How long does the “Naming Conventions for Components” lesson take?

Most CoddyKit lessons take about 5–10 minutes. Each one is bite-sized and interactive, so you make steady progress and pick up exactly where you left off across the web and the app.

Can I write and run code in this Design Systems & Component Libraries lesson?

Yes. Every Design Systems & Component Libraries lesson includes a built-in code editor, so you write and run real code right in your browser and get instant AI feedback — no local setup required.

All lessons in this course

  1. Atomic Design Methodology
  2. Component Anatomy & Structure
  3. Choosing Tech Stack Components
  4. Naming Conventions for Components
← Back to Design Systems & Component Libraries