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
Cajacon diseño especial usado dentro de un solo proyectoA
Cardvariante con diseño personalizado para las pantallas de un solo proyectoVisualizaciones 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 sitioUserMenu- Menú de cuenta de usuarioEstandarizado
ModaldiálogosComponentes 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
Carden lugar de crear una caja personalizada con sombrasUsa
Buttonen lugar de crear un enlace estilizadoUsa
TextFielden lugar de crear un input personalizadoExtender
Dialogen 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.paletteodclColorsEspaciado: Usar
theme.spacing(n)Radio de borde: Usar
theme.shape.borderRadiusTipografía: Usar
theme.typographyvariantesPuntos de quiebre: Usar
theme.breakpointshelpers
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:
Todas las props y variantes
Cada combinación de props
Todas las variantes de tamaño
Todas las variantes de color
Todos los estados
Inactivo/por defecto
Cargando
Error
Deshabilitado
Hover (vía addon de pseudoestados)
Focus (vía addon de pseudoestados)
Interacciones
Manejadores de click
Envíos de formularios
Navegación por teclado
Esquemas de color
Modo claro
Modo oscuro
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:
Propósito - ¿Qué problema resuelve esto?
Uso - Cómo usar el componente
Props - Todas las props con tipos y descripciones
Ejemplos - Casos de uso comunes
Accesibilidad - Soporte de teclado, etiquetas ARIA
Theming - Qué valores del tema utiliza
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:
¿Otros proyectos usarán esto?
No
Sí
¿UI1 tiene un equivalente?
N/A
Probablemente
¿Necesita documentación en Storybook?
No
Sí
¿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?
Sí
No
¿Debe funcionar en todos los temas?
No
Sí
Proceso de aprobación
Componentes específicos del proyecto
Revisión de código por el mantenedor del proyecto
Verificar cumplimiento del tema
Probar en el contexto del proyecto
Merge cuando esté aprobado
Componentes candidatos a UI2
Revisión y aprobación de diseño
Revisión técnica de diseño
Implementación
Historias de Storybook
Pruebas completas
Revisión de accesibilidad
Revisión de código
PR al repositorio UI2
Versionar y publicar
Actualizar proyectos dependientes
Buenas prácticas
Composición sobre personalización
Mejora progresiva
Comenzar simple y añadir funciones según sea necesario:
Versión básica con funcionalidad principal
Agregar comportamiento responsive
Agregar funciones de accesibilidad
Agregar interacciones avanzadas
Optimizar rendimiento
Documentación primero
Antes de escribir código:
Escribir README del componente
Definir la interfaz de props
Listar los estados requeridos
Planear historias de Storybook
Luego implementar
Siguientes pasos
Revisar Estándares de Styling & Theming para detalles de implementación
Ver Guía de migración para migraciones de UI1 a UI2
Comprobar Resumen del proceso para el flujo de trabajo completo
Última actualización