Design Systems & Component Libraries · Lektion

Namenskonventionen für Komponenten

Lernen Sie, wie klare und konsistente Namen für Komponenten und ihre Props eine Komponentenbibliothek auffindbar, vorhersehbar und wartbar machen.

Namenskonventionen für Komponenten ist eine kostenlose Design Systems & Component Libraries-Lektion auf CoddyKit. Dies ist Lektion 4 von 4. Du kannst die komplette Lektion unten kostenlos lesen – dann übst du sie direkt im Browser mit einem integrierten Code-Editor und einem KI-Tutor rund um die Uhr. Sie ist Teil des Design Systems & Component Libraries-Lernpfads, und dein Fortschritt wird über Web und CoddyKit-App synchronisiert. Der Design Systems & Component Libraries-Kurs umfasst insgesamt 4 Lektionen.

Teile dieser Lektion wurden noch nicht übersetzt und werden auf Englisch angezeigt.

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.

Häufig gestellte Fragen

Ist die Lektion „Namenskonventionen für Komponenten“ kostenlos?

Ja — der vollständige Text von „Namenskonventionen für Komponenten“ ist hier im Web kostenlos zu lesen. Um sie interaktiv zu üben (integrierter Code-Editor und 24/7 KI-Tutor) und den Rest des Design Systems & Component Libraries-Kurses freizuschalten, upgrade auf CoddyKit PRO. Der Design Systems & Component Libraries-Kurs umfasst insgesamt 4 Lektionen.

Was lerne ich in „Namenskonventionen für Komponenten“?

Lernen Sie, wie klare und konsistente Namen für Komponenten und ihre Props eine Komponentenbibliothek auffindbar, vorhersehbar und wartbar machen. Du übst Design Systems & Component Libraries mit praktischem Code, den du direkt im Browser ausführst, und ein 24/7 KI-Tutor beantwortet deine Fragen während du die Lektion bearbeitest.

Brauche ich Erfahrung, um Design Systems & Component Libraries zu starten?

Keine Vorkenntnisse erforderlich. Design Systems & Component Libraries auf CoddyKit ist für Anfänger bis fortgeschrittene Lernende strukturiert, sodass du hier starten oder von Anfang an beginnen und in deinem eigenen Tempo voranschreiten kannst. Dies ist Lektion 4 von 4.

Wie lange dauert die Lektion „Namenskonventionen für Komponenten“?

Die meisten CoddyKit-Lektionen dauern etwa 5–10 Minuten. Jede ist kompakt und interaktiv, sodass du stetig Fortschritte machst und genau dort weitermachst, wo du aufgehört hast – im Web und in der App.

Kann ich in dieser Design Systems & Component Libraries-Lektion Code schreiben und ausführen?

Ja. Jede Design Systems & Component Libraries-Lektion enthält einen integrierten Code-Editor, sodass du echten Code direkt in deinem Browser schreibst und ausführst und sofort KI-Feedback erhältst — ohne lokale Einrichtung erforderlich.

Alle Lektionen in diesem Kurs

← Zurück zu Design Systems & Component Libraries