Componentes personalizados

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

Tipos de componentes

A) Componentes personalizados específicos del proyecto

Componentes construidos para un proyecto o pantalla específicos, no destinados a reutilizarse en otros proyectos.

Ejemplos:

  • A Caja con diseño especial usado dentro de un solo proyecto

  • A Card variante con diseño personalizado para las pantallas de un solo proyecto

  • Visualizaciones de datos específicas del proyecto

  • Componentes de diseño únicos

Cuándo usar:

  • El componente resuelve un problema único de un solo proyecto

  • Poco probable que sea necesario en otros proyectos

  • Demasiado específico para generalizar

B) Componentes candidatos a UI2

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

Ejemplos:

  • Navbar - Navegación a nivel del sitio

  • UserMenu - Menú de cuenta de usuario

  • Estandarizado Modal diálogos

  • Componentes que se están migrando desde UI1

Cuándo usar:

  • El componente se utilizará en múltiples proyectos

  • Representa un patrón común de Decentraland

  • Reemplaza o extiende un componente de UI1


Componentes específicos del proyecto

Requisitos

Usar MUI como base

DEBE extender componentes MUI existentes siempre que sea posible:

No bifurcar ni duplicar patrones que MUI ya cubre:

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

  • Usa Button en lugar de crear un enlace estilizado

  • Usa TextField en lugar de crear un input personalizado

  • Extender Dialog en lugar de crear un modal personalizado

Sólo valores del tema

DEBE usar valores del tema UI2:

No se permiten valores arbitrarios:

  • Colores: Usar theme.palette o dclColors

  • Espaciado: Usar theme.spacing(n)

  • Radio de borde: Usar theme.shape.borderRadius

  • Tipografía: Usar theme.typography variantes

  • Puntos de quiebre: Usar theme.breakpoints helpers

Estados y accesibilidad

DEBE definir e implementar todos los estados interactivos:

DEBE implementar accesibilidad básica:**

  • Navegación por teclado - Enfocable y operable con teclado

  • Indicadores de foco - Estados de foco visibles

  • Etiquetas ARIA - Donde el texto no sea visible

  • HTML semántico - Usar elementos apropiados

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

Ejemplo: Componente específico del proyecto


Componentes candidatos a UI2

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

Requisitos

Alineación con el tema

DEBE apoyarse exclusivamente en los valores del tema UI2:

Cobertura en Storybook

DEBE añadir historias de Storybook completas:

Cobertura requerida:

  1. Todas las props y variantes

    • Cada combinación de props

    • Todas las variantes de tamaño

    • Todas las variantes de color

  2. Todos los estados

    • Inactivo/por defecto

    • Cargando

    • Error

    • Deshabilitado

    • Hover (vía addon de pseudoestados)

    • Focus (vía addon de pseudoestados)

  3. Interacciones

    • Manejadores de click

    • Envíos de formularios

    • Navegación por teclado

  4. Esquemas de color

    • Modo claro

    • Modo oscuro

  5. Comportamiento responsivo

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

    • Documentar el comportamiento en cada punto de quiebre

Archivo de ejemplo de Storybook:

Estructura del componente

Los componentes candidatos a UI2 DEBEN seguir esta estructura:

Requisitos de documentación

DEBE incluir en el README del componente:

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

  2. Uso - Cómo usar el componente

  3. Props - Todas las props con tipos y descripciones

  4. Ejemplos - Casos de uso comunes

  5. Accesibilidad - Soporte de teclado, etiquetas ARIA

  6. Theming - Qué valores del tema utiliza

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

README de ejemplo:

Requisitos de testing

DEBE incluir pruebas para:

  • Renderizado de props

  • Interacciones de usuario

  • Funciones de accesibilidad

  • Comportamiento responsivo

  • Estados de error


Matriz de decisión

Usar esto para decidir qué tipo de componente crear:

Pregunta
Específico del proyecto
Candidato a UI2

¿Otros proyectos usarán esto?

No

¿UI1 tiene un equivalente?

N/A

Probablemente

¿Necesita documentación en Storybook?

No

¿Necesita pruebas exhaustivas?

Básicas

Extensas

¿Requiere revisión de diseño?

A nivel de proyecto

A nivel UI2

¿Puede usar patrones específicos del proyecto?

No

¿Debe funcionar en todos los temas?

No


Proceso de aprobación

Componentes específicos del proyecto

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

  2. Verificar cumplimiento del tema

  3. Probar en el contexto del proyecto

  4. Merge cuando esté aprobado

Componentes candidatos a UI2

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

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

  3. Implementación

  4. Historias de Storybook

  5. Pruebas completas

  6. Revisión de accesibilidad

  7. Revisión de código

  8. PR al repositorio UI2

  9. Versionar y publicar

  10. Actualizar proyectos dependientes


Buenas prácticas

Composición sobre personalización

Mejora progresiva

Comenzar simple y añadir funciones según sea necesario:

  1. Versión básica con funcionalidad principal

  2. Agregar comportamiento responsive

  3. Agregar funciones de accesibilidad

  4. Agregar interacciones avanzadas

  5. Optimizar rendimiento

Documentación primero

Antes de escribir código:

  1. Escribir README del componente

  2. Definir la interfaz de props

  3. Listar los estados requeridos

  4. Planear historias de Storybook

  5. Luego implementar


Siguientes pasos

Última actualización