Convenciones de nomenclatura para componentes
Aprenda cómo una nomenclatura clara y coherente de los componentes y sus props hace que una biblioteca de componentes sea fácil de descubrir, predecible y mantenible.
Convenciones de nomenclatura para componentes es una lección gratuita de Design Systems & Component Libraries en CoddyKit. Esta es la lección 4 de 4. Puedes leer la lección completa abajo gratuitamente — luego la practicas en el navegador con un editor de código integrado y un tutor de IA 24/7. Forma parte de la ruta de aprendizaje de Design Systems & Component Libraries, y tu progreso se sincroniza en la web y la app de CoddyKit. El curso de Design Systems & Component Libraries incluye 4 lecciones en total.
Partes de esta lección aún no han sido traducidas y se muestran en 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:
variantfor visual style (primary, ghost)sizefor scale (sm, md, lg)onChange,onClickfor 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.
Preguntas frecuentes
¿La lección «Convenciones de nomenclatura para componentes» es gratis?
Sí — el texto completo de «Convenciones de nomenclatura para componentes» es gratis para leer aquí en la web. Para practicarla de forma interactiva (editor de código integrado y tutor de IA 24/7) y desbloquear el resto del curso de Design Systems & Component Libraries, actualiza a CoddyKit PRO. El curso de Design Systems & Component Libraries incluye 4 lecciones en total.
¿Qué aprenderé en «Convenciones de nomenclatura para componentes»?
Aprenda cómo una nomenclatura clara y coherente de los componentes y sus props hace que una biblioteca de componentes sea fácil de descubrir, predecible y mantenible. Practicas Design Systems & Component Libraries con código real que ejecutas directamente en el navegador, y un tutor de IA 24/7 responde tus preguntas mientras trabajas en la lección.
¿Necesito experiencia previa para empezar Design Systems & Component Libraries?
No se requiere experiencia previa. Design Systems & Component Libraries en CoddyKit está estructurado para principiantes hasta estudiantes avanzados, así que puedes empezar aquí o desde el inicio y avanzar a tu ritmo. Esta es la lección 4 de 4.
¿Cuánto tiempo toma la lección «Convenciones de nomenclatura para componentes»?
La mayoría de las lecciones de CoddyKit toman alrededor de 5–10 minutos. Cada una es compacta e interactiva, así que avanzas constantemente y retomas exactamente por donde dejaste en la web y la app.
¿Puedo escribir y ejecutar código en esta lección de Design Systems & Component Libraries?
Sí. Cada lección de Design Systems & Component Libraries incluye un editor de código integrado, así que escribes y ejecutas código real directamente en tu navegador y obtienes retroalimentación instantánea de IA — sin configuración local necesaria.
Todas las lecciones de este curso
- Metodología Atomic Design
- Anatomía y estructura de los componentes
- Elección de componentes del stack tecnológico
- Convenciones de nomenclatura para componentes