For the complete documentation index, see llms.txt. This page is also available as Markdown.

Componentes personalizados

Distinguimos entre dos tipos de componentes personalizados, cada uno con diferentes procesos y expectativas.

Tipos de componente

A) Componentes personalizados específicos del proyecto

Componentes creados para un proyecto o pantalla específicos, no pensados para reutilizarse en otros proyectos.

Ejemplos:

  • Un Box con un diseño especial usado dentro de un proyecto

  • Un Card variante con un diseño a medida para las pantallas de un proyecto

  • Visualizaciones de datos específicas del proyecto

  • Componentes de diseño puntuales

Cuándo usarlo:

  • El componente resuelve un problema único de un proyecto

  • Es poco probable que se necesite en otros proyectos

  • Demasiado específico para generalizar

B) Componentes candidatos de UI2

Componentes destinados a reutilizarse en múltiples proyectos y productos.

Ejemplos:

  • Navbar - Navegación de todo el sitio

  • UserMenu - Menú de cuenta de usuario

  • Estandarizado Modal diálogos

  • Componentes que se están migrando desde UI1

Cuándo usarlo:

  • El componente se usará en múltiples proyectos

  • Representa un patrón común de Decentraland

  • Reemplaza o amplía un componente de UI1


Componentes específicos del proyecto

Requisitos

Usa MUI como base

DEBE amplía los componentes MUI existentes siempre que sea posible:

No hagas fork ni dupliques patrones que MUI ya cubre:

  • Usa Card en lugar de crear una caja personalizada con sombras

  • Usa Button en lugar de crear un enlace con estilo

  • Usa TextField en lugar de crear un input personalizado

  • Amplía Dialog en lugar de crear un modal personalizado

Solo valores del theme

DEBE usa valores del theme de UI2:

No se permiten valores arbitrarios:

  • Colores: usa theme.palette o dclColors

  • Espaciado: usa theme.spacing(n)

  • Radio del borde: usa theme.shape.borderRadius

  • Tipografía: usa theme.typography variantes

  • Puntos de quiebre: usa theme.breakpoints funciones auxiliares

Estados y accesibilidad

DEBE define e implementa todos los estados interactivos:

DEBE implementa accesibilidad básica:**

  • Navegación por teclado - Se puede enfocar y operar con el teclado

  • Indicadores de foco - Estados de foco visibles

  • Etiquetas ARIA - Cuando el texto no es visible

  • HTML semántico - Usa elementos apropiados

  • Contraste de color - Cumple con los estándares WCAG AA

Ejemplo: componente específico del proyecto


Componentes candidatos de UI2

Los componentes que se compartirán entre proyectos requieren estándares más altos y documentación más exhaustiva.

Requisitos

Alineación con el theme

DEBE depende exclusivamente de los valores del theme de UI2:

Cobertura de Storybook

DEBE añade stories completas de Storybook:

Cobertura requerida:

  1. Todos los props y variantes

    • Todas las combinaciones de props

    • Todas las variantes de tamaño

    • Todas las variantes de color

  2. Todos los estados

    • Inactivo/predeterminado

    • Cargando

    • Error

    • Deshabilitado

    • Hover (mediante el addon de pseudo states)

    • Focus (mediante el addon de pseudo states)

  3. Interacciones

    • Manejadores de click

    • Envíos de formularios

    • Navegación por teclado

  4. Esquemas de color

    • Modo claro

    • Modo oscuro

  5. Comportamiento responsive

    • Puntos de quiebre clave (xs, md, lg)

    • Documenta el comportamiento en cada punto de quiebre

Ejemplo de archivo de Storybook:

Estructura del componente

Los componentes candidatos de UI2 DEBERÍAN seguir esta estructura:

Requisitos de documentación

DEBE incluye en el README del componente:

  1. Propósito - ¿Qué problema resuelve?

  2. Uso - Cómo usar el componente

  3. Props - Todos los props con tipos y descripciones

  4. Ejemplos - Casos de uso comunes

  5. Accesibilidad - Soporte de teclado, etiquetas ARIA

  6. Tema - Qué valores del theme usa

  7. Notas de migración - Si reemplaza un componente de UI1

Ejemplo de README:

Requisitos de pruebas

DEBE incluye pruebas para:

  • Renderizado de props

  • Interacciones del usuario

  • Funciones de accesibilidad

  • Comportamiento responsive

  • Estados de error


Matriz de decisión

Usa esto para decidir qué tipo de componente crear:

Pregunta
Específico del proyecto
Candidato de UI2

¿Lo usarán otros proyectos?

No

Sí

¿UI1 tiene un equivalente?

N/A

Probablemente

¿Necesita documentación de Storybook?

No

Sí

¿Necesita pruebas exhaustivas?

Básico

Exhaustivo

¿Se requiere revisión de diseño?

A nivel de proyecto

A nivel de UI2

¿Se pueden usar patrones específicos del proyecto?

Sí

No

¿Debe funcionar en todos los themes?

No

Sí


Proceso de aprobación

Componentes específicos del proyecto

  1. Revisión de código por el mantenedor del proyecto

  2. Verificar cumplimiento con el theme

  3. Probar en el contexto del proyecto

  4. Fusionar cuando se apruebe

Componentes candidatos de UI2

  1. Revisión y aprobación de diseño

  2. Revisión técnica del diseño

  3. Implementación

  4. stories de Storybook

  5. Pruebas exhaustivas

  6. Revisión de accesibilidad

  7. Revisión de código

  8. PR al repositorio de UI2

  9. Versionar y publicar

  10. Actualizar los proyectos dependientes


Buenas prácticas

Composición sobre personalización

Mejora progresiva

Empieza simple y añade funciones según sea necesario:

  1. Versión básica con funcionalidad principal

  2. Añade comportamiento adaptable

  3. Añade funciones de accesibilidad

  4. Añade interacciones avanzadas

  5. Optimiza el rendimiento

La documentación primero

Antes de escribir código:

  1. Escribe el README del componente

  2. Define la interfaz de props

  3. Enumera los estados requeridos

  4. Planifica las historias de Storybook

  5. Luego implementa


Próximos pasos

Última actualización