0Pricing
Design Systems & Component Libraries · Lezione

Convenzioni di denominazione dei componenti

Impari come una denominazione chiara e coerente dei componenti e delle relative props renda una component library facile da esplorare, prevedibile e manutenibile.

Convenzioni di denominazione dei componenti è una lezione Design Systems & Component Libraries gratuita su CoddyKit. Questa è la lezione 4 di 4. Puoi leggere la lezione completa qui gratuitamente — poi esercitati direttamente nel browser con un editor di codice integrato e un tutor IA disponibile 24/7. Fa parte del percorso di apprendimento Design Systems & Component Libraries, e i tuoi progressi si sincronizzano tra il web e l'app CoddyKit. Il corso Design Systems & Component Libraries include 4 lezioni in totale.

Parti di questa lezione non sono ancora state tradotte e vengono mostrate in inglese.

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.

Domande Frequenti

La lezione «Convenzioni di denominazione dei componenti» è gratuita?

Sì — il testo completo di «Convenzioni di denominazione dei componenti» è gratuito qui sul web. Per esercitarvi in modo interattivo (un editor di codice integrato e un tutor IA 24/7) e sbloccare il resto del corso Design Systems & Component Libraries, passa a CoddyKit PRO. Il corso Design Systems & Component Libraries include 4 lezioni in totale.

Cosa imparerò in «Convenzioni di denominazione dei componenti»?

Impari come una denominazione chiara e coerente dei componenti e delle relative props renda una component library facile da esplorare, prevedibile e manutenibile. Eserciti Design Systems & Component Libraries con codice pratico che esegui direttamente nel browser, e un tutor IA 24/7 risponde alle tue domande mentre lavori sulla lezione.

Ho bisogno di esperienza per iniziare Design Systems & Component Libraries?

Non è richiesta alcuna esperienza precedente. Design Systems & Component Libraries su CoddyKit è strutturato per principianti e studenti avanzati, quindi puoi iniziare da qui o dall'inizio e procedere al tuo ritmo. Questa è la lezione 4 di 4.

Quanto tempo richiede la lezione «Convenzioni di denominazione dei componenti»?

La maggior parte delle lezioni CoddyKit richiede circa 5–10 minuti. Ogni lezione è breve e interattiva, quindi fai progressi costanti e riprendi esattamente da dove hai lasciato su web e app.

Posso scrivere ed eseguire codice in questa lezione Design Systems & Component Libraries?

Sì. Ogni lezione Design Systems & Component Libraries include un editor di codice integrato, quindi scrivi ed esegui codice reale direttamente nel tuo browser e ricevi feedback istantaneo dall'IA — nessuna configurazione locale necessaria.

Tutte le lezioni di questo corso

  1. Metodologia Atomic Design
  2. Anatomia e struttura dei componenti
  3. Scelta dei componenti dello stack tecnologico
  4. Convenzioni di denominazione dei componenti
← Torna a Design Systems & Component Libraries