Estilismo y CSS - AWS Orientación prescriptiva

Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.

Estilismo y CSS

Las hojas de estilo en cascada (CSS) son un lenguaje para determinar de forma centralizada la presentación de un documento en lugar de codificar el formato del texto y los objetos. La función de cascada del lenguaje está diseñada para controlar las prioridades entre los estilos mediante el uso de la herencia. Cuando se trabaja con microinterfaces y se crea una estrategia para gestionar las dependencias, la función de cascada del lenguaje puede ser todo un desafío.

Por ejemplo, dos microinterfaces coexisten en la misma página y cada una define su propio estilo para el elemento HTML. body Si cada uno busca su propio archivo CSS y lo adjunta al DOM mediante una style etiqueta, el archivo CSS reemplaza al primero si ambos tienen definiciones de elementos HTML, nombres de clases o identificadores de elementos comunes. Existen diferentes estrategias para solucionar estos problemas, en función de la estrategia de dependencia que se elija para gestionar los estilos.

En la actualidad, el enfoque más popular para equilibrar el rendimiento, la coherencia y la experiencia del desarrollador consiste en desarrollar y mantener un sistema de diseño.

Diseñar sistemas: un enfoque basado en compartir algo

Este enfoque utiliza un sistema para compartir estilos cuando es apropiado y, al mismo tiempo, admite divergencias ocasionales para equilibrar la coherencia, el rendimiento y la experiencia del desarrollador. Un sistema de diseño es un conjunto de componentes reutilizables, guiados por normas claras. El desarrollo del sistema de diseño suele estar impulsado por un equipo con las aportaciones y contribuciones de muchos equipos. En términos prácticos, un sistema de diseño es una forma de compartir elementos de bajo nivel que se pueden exportar como una JavaScript biblioteca. Los desarrolladores con microinterfaces pueden utilizar la biblioteca como una dependencia para crear interfaces sencillas componiendo los recursos disponibles previamente y como punto de partida para crear nuevas interfaces.

Considere el ejemplo de una microinterfaz que necesita un formulario. La experiencia típica de un desarrollador consiste en utilizar componentes prefabricados disponibles en el sistema de diseño para crear cuadros de texto, botones, listas desplegables y otros elementos de la interfaz de usuario. El desarrollador no necesita escribir ningún estilo para los componentes reales, solo para determinar el aspecto que tienen juntos. El sistema que se va a construir y lanzar puede utilizar webpack Module Federation o un enfoque similar para declarar el sistema de diseño como una dependencia externa, de modo que la lógica del formulario se empaquete sin incluir el sistema de diseño.

De este modo, varias microinterfaces pueden hacer lo mismo para resolver problemas comunes. Cuando los equipos desarrollan nuevos componentes que pueden compartirse entre múltiples microinterfaces, esos componentes se añaden al sistema de diseño una vez que alcanzan su madurez.

Una de las principales ventajas del enfoque del sistema de diseño es el alto nivel de coherencia. Si bien las microinterfaces pueden escribir estilos y, en ocasiones, anular los del sistema de diseño, es muy poco necesario. Los principales elementos de bajo nivel no cambian con frecuencia y ofrecen una funcionalidad básica que se puede ampliar de forma predeterminada. Otra ventaja es el rendimiento. Con una buena estrategia de creación y publicación, puede producir un mínimo de paquetes compartidos que estén instrumentados por el shell de la aplicación. Puede mejorar aún más si se cargan de forma asíncrona varios paquetes específicos de microinterfaz según demanda, con un consumo mínimo en términos de ancho de banda de red. Por último, pero no por ello menos importante, la experiencia de los desarrolladores es ideal, ya que las personas pueden centrarse en crear interfaces sofisticadas sin tener que reinventar la rueda (por ejemplo, escribir JavaScript y usar CSS cada vez que es necesario añadir un botón a una página).

La desventaja es que un sistema de diseño de cualquier tipo es una dependencia, por lo que debe mantenerse y, en ocasiones, actualizarse. Si varias microinterfaces requieren una nueva versión de una dependencia compartida, puede usar una de las siguientes opciones:

  • Un mecanismo de organización que, de vez en cuando, puede recuperar varias versiones de esa dependencia compartida sin conflictos

  • Una estrategia compartida para hacer que todos los dependientes usen una nueva versión

Por ejemplo, si todas las microinterfaces dependen de la versión 3.0 de un sistema de diseño y hay una nueva versión llamada 3.1 que se utiliza de forma compartida, puede implementar indicadores de características para que todas las microinterfaces migren con un riesgo mínimo. Para obtener más información, consulte la sección Indicadores de características. Otro posible inconveniente es que los sistemas de diseño suelen abordar algo más que el estilo. También incluyen JavaScript prácticas y herramientas. Estos aspectos requieren llegar a un consenso a través del debate y la colaboración.

Implementar un sistema de diseño es una buena inversión a largo plazo. Es un enfoque popular y cualquiera que trabaje en una arquitectura de frontend compleja debería tenerlo en cuenta. Por lo general, requiere que los ingenieros de front-end y los equipos de producto y diseño colaboren y definan mecanismos para interactuar entre sí. Es importante programar el tiempo para alcanzar el estado deseado. También es importante contar con el patrocinio de los líderes para que las personas puedan construir algo confiable, bien mantenido y que rinda bien a largo plazo.

CSS totalmente encapsulado: un enfoque de no compartir nada

Cada microinterfaz utiliza convenciones y herramientas para superar la función de cascada del CSS. Un ejemplo es garantizar que el estilo de cada elemento esté siempre asociado a un nombre de clase en lugar de a su ID, y que los nombres de clase sean siempre únicos. De esta forma, todo depende de las microinterfaces individuales y se minimiza el riesgo de conflictos no deseados. Por lo general, el shell de la aplicación se encarga de cargar los estilos de las microinterfaces una vez que se han cargado en el DOM, aunque algunas herramientas agrupan los estilos mediante el uso de estos. JavaScript

La principal ventaja de no compartir nada es el menor riesgo de que se produzcan conflictos entre las microinterfaces. Otra ventaja es la experiencia del desarrollador. Cada microinterfaz no comparte nada con otras microinterfaces. Publicar y probar de forma aislada es más sencillo y rápido.

Una desventaja principal del enfoque de no compartir nada es la posible falta de coherencia. No existe ningún sistema para evaluar la coherencia. Aunque el objetivo es duplicar lo que se comparte, resulta difícil equilibrar la velocidad de publicación y la colaboración. Una mitigación habitual consiste en crear herramientas para medir la coherencia. Por ejemplo, puedes crear un sistema para realizar capturas de pantalla automatizadas de varias microinterfaces renderizadas en una página con un navegador sin interfaz gráfica. A continuación, puedes revisar manualmente las capturas de pantalla antes del lanzamiento. Sin embargo, eso requiere disciplina y gobierno. Para obtener más información, consulte la sección Equilibrar la autonomía con la alineación.

Según el caso de uso, otra posible desventaja es el rendimiento. Si todas las microinterfaces utilizan una gran cantidad de estilos, el cliente debe descargar una gran cantidad de código duplicado. Eso afectará negativamente a la experiencia del usuario.

Este enfoque de «no compartir nada» debería considerarse únicamente en el caso de arquitecturas de microinterfaces en las que participan solo unos pocos equipos, o en las microinterfaces que toleran una baja coherencia. También puede ser un paso inicial natural mientras una organización trabaja en un sistema de diseño.

CSS global compartido: un enfoque que permite compartirlo todo

Con este enfoque, todo el código relacionado con el estilo se almacena en un repositorio central donde los colaboradores escriben CSS para todas las microinterfaces trabajando en archivos CSS o utilizando preprocesadores como Sass. Cuando se realizan cambios, un sistema de compilación crea un único paquete de CSS que se puede alojar en una CDN e incluir en cada microinterfaz mediante el shell de la aplicación. Los desarrolladores de microinterfaces pueden diseñar y crear sus aplicaciones ejecutando su código a través de una consola de aplicaciones alojada localmente.

Además de la evidente ventaja de reducir el riesgo de conflictos entre las microinterfaces, las ventajas de este enfoque son la coherencia y el rendimiento. Sin embargo, al disociar los estilos del marcado y la lógica, los desarrolladores tienen más dificultades para entender cómo se utilizan los estilos, cómo pueden evolucionar y cómo pueden quedar obsoletos. Por ejemplo, puede resultar más rápido introducir un nombre de clase nuevo que aprender sobre la clase existente y las consecuencias de editar sus propiedades. Las desventajas de crear un nombre de clase nuevo son el aumento del tamaño del paquete, que afecta al rendimiento, y la posible introducción de incoherencias en la experiencia del usuario.

Si bien un CSS global compartido puede ser el punto de partida de una monolith-to-micro-frontends migración, rara vez resulta beneficioso para las arquitecturas microfrontend en las que participan más de uno o dos equipos que colaboran entre sí. Recomendamos invertir en un sistema de diseño lo antes posible e implementar un enfoque de no compartir nada mientras el sistema de diseño esté en desarrollo.