0Pricing
Design Systems & Component Libraries · Aula

Convenções de Nomenclatura para Componentes

Aprenda como nomear componentes e suas propriedades de forma clara e consistente torna uma biblioteca de componentes fácil de explorar, previsível e sustentável.

Convenções de Nomenclatura para Componentes é uma aula grátis de Design Systems & Component Libraries no CoddyKit. Esta é a aula 4 de 4. Você pode ler a aula completa abaixo gratuitamente — depois pratica ao vivo no navegador com um editor de código integrado e um tutor de IA 24/7. Faz parte do caminho de aprendizado de Design Systems & Component Libraries, e seu progresso é sincronizado entre a web e o app CoddyKit. O curso de Design Systems & Component Libraries inclui 4 aulas no total.

Partes desta aula ainda não foram traduzidas e aparecem em inglês.

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.

Perguntas Frequentes

A aula “Convenções de Nomenclatura para Componentes” é grátis?

Sim — o texto completo de “Convenções de Nomenclatura para Componentes” é grátis para ler aqui na web. Para praticá-la interativamente (um editor de código integrado e um tutor de IA 24/7) e desbloquear o restante do curso de Design Systems & Component Libraries, atualize para CoddyKit PRO. O curso de Design Systems & Component Libraries inclui 4 aulas no total.

O que vou aprender em “Convenções de Nomenclatura para Componentes”?

Aprenda como nomear componentes e suas propriedades de forma clara e consistente torna uma biblioteca de componentes fácil de explorar, previsível e sustentável. Você pratica Design Systems & Component Libraries com código prático que executa diretamente no navegador, e um tutor de IA 24/7 responde suas dúvidas enquanto trabalha na aula.

Preciso ter experiência prévia para começar Design Systems & Component Libraries?

Nenhuma experiência prévia é necessária. Design Systems & Component Libraries no CoddyKit é estruturado para alunos iniciantes até avançados, então você pode começar aqui ou desde o início e aprender no seu ritmo. Esta é a aula 4 de 4.

Quanto tempo leva a aula “Convenções de Nomenclatura para Componentes”?

A maioria das aulas CoddyKit leva cerca de 5–10 minutos. Cada uma é compacta e interativa, então você faz progresso constante e retoma exatamente de onde parou entre web e app.

Posso escrever e executar código nesta aula de Design Systems & Component Libraries?

Sim. Cada aula de Design Systems & Component Libraries inclui um editor de código integrado, então você escreve e executa código real direto no navegador e recebe feedback de IA instantaneamente — nenhuma configuração local necessária.

Todas as aulas deste curso

  1. Metodologia do Design Atômico
  2. Anatomia e estrutura dos componentes
  3. Escolha dos Componentes da Pilha Tecnológica
  4. Convenções de Nomenclatura para Componentes
← Voltar para Design Systems & Component Libraries