Crear una librería de componentes UI con Angular: errores a evitar para tener éxito

He trabajado en varias empresas creando librerías de UI o frameworks internos para usarlos en múltiples productos, con el sueño de tener una gran interfaz, consistencia y el mismo comportamiento para los usuarios.

La idea de una librería de UI ayuda a que los desarrolladores eviten duplicar componentes, acelera el desarrollo y ofrece la misma experiencia en todo el ecosistema de la empresa.

En este post, quiero contarte parte de mi experiencia en este proceso, y espero que te sirva para tomar atajos o evitar cometer mis mismos errores.

Cuando una empresa asume el reto de crear una librería de componentes no es una tarea sencilla, va mucho más allá de simplemente crear un proyecto con un montón de componentes.

Tenemos que pensar en lo siguiente:

• ¿Cómo compartir la librería entre diferentes proyectos?

• ¿Cómo distribuirla y entregarla?

• ¿Qué tan fácil es para alguien nuevo empezar a colaborar en ella?

• ¿Cómo compartir los casos de uso que cubre la librería?

• ¿Qué tan flexible debe ser?

• Y muchos otros aspectos.

Ahora quiero mostrarte los puntos de fallo más comunes al crear una librería de UI:

• No crear un sistema de diseño primero.

• No pensar en la entrega y distribución.

• Descuidar la API de los componentes.

• Crear componentes acoplados a la lógica de negocio.

• Aislar al equipo de UI.

• Usar las herramientas equivocadas.

Sistema de diseño

El sistema de diseño nos ayuda a entender el estado de nuestra UI, ver cuántos componentes son similares, elegir los puntos de partida para la librería y crear una lista de elementos o características esenciales.

Por desgracia, casi siempre me ha tocado trabajar sobre aplicaciones existentes con componentes y comportamientos ya complejos. En esos casos, reviso cada área o módulo de la aplicación y creo mi propio "Inventario de interfaces" (Interface Inventory).

Puedes leer más sobre el Interface Inventory.

El inventario de interfaces nos ayuda a definir la base y la lista de los elementos más utilizados, las diferentes versiones de un mismo elemento visual, y apoyarnos en atomic design para que luego sea fácil componer componentes en el futuro.

Puedes leer más sobre Atomic Design.

Entrega y distribución

Ten mucho cuidado con cómo distribuyes y entregas tus componentes, tanto para quienes los desarrollan como para quienes los consumen. Si empaquetas todos tus componentes acoplados entre sí en un único paquete como este:

npm install @my_amazing_library

Para componentes empresariales grandes donde cada componente tiene su propia hoja de ruta y funcionalidades distintas, un solo paquete no es una buena idea. Te obliga a actualizar las versiones de todos los componentes de la librería al mismo tiempo, lo que complica las actualizaciones y no permite entregar una versión específica.

Separar los componentes y sus versiones nos ayuda a ofrecer actualizaciones pequeñas e incrementales, evita conflictos de dependencias redundantes, mejora el rendimiento y la estabilidad, sin forzar a actualizar todo si no lo necesitas.

components
   ├─ grid-footer       5.1.1
   ├─ grid-action-button 	   1.1.0
   ├─ grid-header  3.7.6

API de componentes y flexibilidad

Crear una API de componentes flexible se relaciona mucho con el problema del "Equipo de UI aislado", pero siempre debemos tener presente quién va a usar nuestros componentes.

Una solución es escribir un borrador antes de codificar, o pensar primero en cómo otros desarrolladores van a usar nuestros componentes. Esto nos permite diseñar una API semántica.

Entender el contexto ayuda a crear componentes claros y semánticos como este:

<amazing-chart>
	<amazing-chart-title></amazing-chart-title>
	<amazing-chart-row></amazing-chart-row>
</amazing-chart>

En Angular podemos exponer el estado del componente en la plantilla usando exportAs. Esto ayuda a compartir el estado rápidamente y reduce la necesidad de inyectar cosas solo para comunicar componentes.

Puedes leer más sobre exportAs.

Ten en cuenta la usabilidad y la composición en nuestros componentes: permite componentes hijos con <ng-content></ng-content> y construye componentes compuestos (compound components).

Puedes leer más sobre componentes compuestos.

Ten en mente que el objetivo principal es la flexibilidad para ofrecer componentes funcionales.

El equipo de UI

Soy un gran fanático de la NBA, y siempre tengo presente esta idea: dos jugadores pueden ganar partidos, pero los campeonatos se ganan trabajando en equipo. El equipo de UI necesita trabajar de la mano con toda la empresa, no programar en soledad o de forma aislada. La librería de componentes es para la empresa, no solo para el equipo de UI.

Si un equipo se enfoca únicamente en la librería de UI sin compartirla ni recibir feedback de sus usuarios (los otros desarrolladores o productos que la usan), terminará creando una librería desconectada de los escenarios y problemas reales de la empresa.

Ten presentes estos puntos:

• La librería de UI debe estar abierta para que otros desarrolladores o representantes de equipo puedan publicar o proponer componentes.

• Comparte el conocimiento con los nuevos integrantes mediante guías para publicar componentes.

• Construye tu equipo de UI con un representante de cada producto o módulo.

Usa las herramientas adecuadas

Angular ofrece varias opciones para construir nuestra librería de UI. El Angular CLI permite trabajar con múltiples proyectos para dividir el código en varios paquetes, pero no es suficiente.

• ¿Cómo gestionas múltiples proyectos?

• ¿Cómo comunica el equipo de UI los componentes?

• ¿Qué pasa con las pruebas?

• ¿Cómo mantienes las librerías actualizadas?

No pretendo decirte cuál es la "solución dorada" o la bala de plata, pero estas herramientas son mi recomendación personal:

• Angular: https://angular.io/ ¡Mi querido framework de JavaScript! :)

• Nx: https://nx.dev/ Una herramienta genial para monorepos, todo el código en un solo lugar con consistencia y gestión sencilla de dependencias.

• StoryBook: https://storybook.js.org/ Un entorno de pruebas (sandbox) sencillo para que otros desarrolladores y la empresa prueben los componentes de UI con documentación y casos de uso (stories) de forma fácil.

• Cypress: https://www.cypress.io/ Cubre pruebas e2e y component testing para probar tus componentes rápidamente.

• Jest: https://jestjs.io/ Pruebas unitarias para servicios y lógica de negocio.

Resumen

La creación de una librería de UI es una gran responsabilidad. Tómate tu tiempo antes de empezar para entender bien los requerimientos de la empresa.

Una librería de UI es una inversión de tiempo y recursos para la empresa, pero el retorno de inversión va más allá del código. Hace que el desarrollador trabaje más rápido y facilita acelerar el desarrollo.

Quizás se me escape algún otro punto. Si quieres agregar algo más, por favor déjame un comentario.

Foto de Sen en Unsplash