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
Boxcon un diseño especial usado dentro de un proyectoUn
Cardvariante con un diseño a medida para las pantallas de un proyectoVisualizaciones 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 sitioUserMenu- Menú de cuenta de usuarioEstandarizado
ModaldiálogosComponentes 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
Carden lugar de crear una caja personalizada con sombrasUsa
Buttonen lugar de crear un enlace con estiloUsa
TextFielden lugar de crear un input personalizadoAmplía
Dialogen 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.paletteodclColorsEspaciado: usa
theme.spacing(n)Radio del borde: usa
theme.shape.borderRadiusTipografía: usa
theme.typographyvariantesPuntos de quiebre: usa
theme.breakpointsfunciones 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:
Todos los props y variantes
Todas las combinaciones de props
Todas las variantes de tamaño
Todas las variantes de color
Todos los estados
Inactivo/predeterminado
Cargando
Error
Deshabilitado
Hover (mediante el addon de pseudo states)
Focus (mediante el addon de pseudo states)
Interacciones
Manejadores de click
Envíos de formularios
Navegación por teclado
Esquemas de color
Modo claro
Modo oscuro
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:
Propósito - ¿Qué problema resuelve?
Uso - Cómo usar el componente
Props - Todos los props con tipos y descripciones
Ejemplos - Casos de uso comunes
Accesibilidad - Soporte de teclado, etiquetas ARIA
Tema - Qué valores del theme usa
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:
¿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
Revisión de código por el mantenedor del proyecto
Verificar cumplimiento con el theme
Probar en el contexto del proyecto
Fusionar cuando se apruebe
Componentes candidatos de UI2
Revisión y aprobación de diseño
Revisión técnica del diseño
Implementación
stories de Storybook
Pruebas exhaustivas
Revisión de accesibilidad
Revisión de código
PR al repositorio de UI2
Versionar y publicar
Actualizar los proyectos dependientes
Buenas prácticas
Composición sobre personalización
Mejora progresiva
Empieza simple y añade funciones según sea necesario:
Versión básica con funcionalidad principal
Añade comportamiento adaptable
Añade funciones de accesibilidad
Añade interacciones avanzadas
Optimiza el rendimiento
La documentación primero
Antes de escribir código:
Escribe el README del componente
Define la interfaz de props
Enumera los estados requeridos
Planifica las historias de Storybook
Luego implementa
Próximos pasos
Revisar estilo y tematización para detalles de implementación
Ver Guía de migración para migraciones de UI1 a UI2
Revisa Resumen del proceso para el flujo de trabajo completo
Última actualización