Una sola apariencia entre microfrontends: tokens, componentes y aislamiento de estilos

Los usuarios no saben que tu producto lo construyen cinco equipos, y nunca deberían enterarse por los botones. Un design system compartido es lo que mantiene a equipos independientes produciendo un solo producto.

Por qué va primero

En una aplicación única, la consistencia visual ocurre en parte por accidente. Todos copian del mismo código. Cuando los equipos publican por separado, ese accidente se acaba. Cada equipo resuelve los mismos problemas de formas un poco distintas, y en un año el producto parece varios productos.

Un design system es la contramedida. También es una condición previa: empezar con microfrontends sin tenerlo significa pagarlo después, con un rediseño encima.

Tres capas

Design tokens

Los tokens son valores con nombre: colores, espaciado, tipografía, radios, sombras, niveles de z-index. Entregados como CSS custom properties, funcionan en cualquier framework y dentro de Shadow DOM.

:root {
  --color-primary: #0b5fff;
  --space-2: 8px;
  --radius-md: 6px;
}

El host carga los tokens una vez. Un cambio de marca o un tema oscuro pasa a ser un cambio de valores de tokens, visible en todos los remotos al mismo tiempo.

Librería de componentes

Botones, inputs, tablas, diálogos y los demás bloques de construcción, hechos sobre los tokens. En una plataforma solo Angular, es una librería Angular. En una plataforma con varios frameworks, las opciones son web components, o tokens más CSS plano con una implementación delgada por framework.

Patrones y guías

Cómo valida un formulario, cómo se ve un estado vacío, cómo se redactan los errores, cómo se organiza una página. Viven en documentación con ejemplos en vivo. Storybook es una herramienta común para esto.

Compartido en tiempo de ejecución o incluido en cada remoto

Un punto medio práctico:

• Los tokens siempre vienen del host en tiempo de ejecución.
• La librería de componentes se comparte como singleton dentro de una misma versión mayor. Los equipos toman las versiones menores libremente.
• Las versiones mayores se adoptan dentro de una ventana acordada. Durante esa ventana pueden convivir dos versiones mayores, y cada remoto incluye la suya.

La mecánica de compartir está en Dependencias compartidas y versiones.

Cómo versionar el design system

• Sigue el versionado semántico de forma estricta. Quitar un input, renombrar un token o cambiar el tamaño de un componente es un cambio incompatible.
• Depreca antes de eliminar. Un componente deprecado se mantiene al menos una versión mayor, con una advertencia y un reemplazo documentado.
• Soporta un número limitado de versiones mayores. La actual y la anterior es una regla común. Las más antiguas no reciben arreglos.

Cómo evitar fugas de estilos

Con federation en tiempo de ejecución, todos los remotos comparten un mismo documento, así que el CSS de uno puede alcanzar a otro. Las fuentes habituales:

• Selectores globales de elementos. Un remoto que aplica estilos globales a button o h1 cambia el estilo de todo el producto. Solo el design system define estilos base.
• Encapsulación desactivada. Angular acota los estilos de los componentes por defecto. ViewEncapsulation.None y ::ng-deep son las vías de escape habituales. Márcalos en la revisión de código o con una regla de lint.
• CSS global de terceros. Un remoto que importa un framework CSS completo afecta a todos. Prohíbelo, o acótalo bajo la clase raíz del remoto.
• Overlays. Los diálogos, menús y tooltips suelen mostrarse en un contenedor al final del documento, fuera del subárbol DOM del remoto. Usa los componentes de overlay del design system, y comparte la librería que hay debajo como singleton para que exista un solo contenedor.
• Orden de apilamiento. Define los niveles de z-index como tokens. Los valores arbitrarios en los remotos terminan en diálogos escondidos detrás de encabezados.

Para los remotos envueltos como web components, Shadow DOM da un aislamiento fuerte de estilos. Las custom properties atraviesan el límite del shadow, y por eso los tokens funcionan bien ahí.

Gobernanza

• Un dueño. Un equipo pequeño de design system, o el equipo de plataforma junto con un diseñador.
• Un modelo de contribución. Los equipos de producto proponen y construyen componentes, y los dueños los revisan. Sin esto, el equipo del design system se vuelve un cuello de botella y los equipos construyen variantes locales.
• Una regla de promoción. Un componente que necesitan dos equipos pasa a la librería.
• Pruebas de regresión visual en la librería, para que un cambio en un botón se vea antes de que cinco equipos lo descubran. Las pruebas del producto compuesto se cubren en Pruebas en microfrontends.

Checklist

1. ¿Los tokens se cargan una vez, desde el host?
2. ¿La librería de componentes es un singleton compartido con una política de versiones?
3. ¿Hay una regla de lint o un control en la revisión para selectores globales y encapsulación desactivada?
4. ¿Sabes qué versión del design system corre hoy cada remoto?

Más en esta sección

• CI/CD para microfrontends: pipelines independientes, descubrimiento y rollbacks
• Aislamiento de errores y resiliencia en microfrontends
• Rendimiento de microfrontends: los costos y cómo controlarlos
• Pruebas en microfrontends: una estrategia práctica