He trabajado en algunas empresas construyendo una biblioteca de interfaz de usuario o framework de empresa para utilizarlo en múltiples productos con el sueño de tener una gran interfaz de usuario, consistencia y el mismo comportamiento para los usuarios.

La idea de la biblioteca de interfaz de usuario ayuda a los desarrolladores a evitar la duplicidad de componentes, acelera el desarrollo, y ofrece la misma experiencia en el ecosistema de la empresa.

En este post, explicaré la parte del viaje en el proceso, y espero que os ayude a tomar atajos o a saltaros mis errores.

Cuando la empresa asume el reto de construir una biblioteca de componentes no es una tarea fácil, es más que crear un proyecto con un montón de componentes.

Tenemos que pensar en lo siguiente:

• ¿Cómo compartir la biblioteca entre proyectos?
• ¿Cómo será la distribución (npm, agregar script, etc.)?
• ¿Qué facilidad tiene un nuevo integrante para colaborar con ella?
• ¿Cómo compartir los casos de uso cubiertos por la biblioteca?
• ¿Cómo de flexible tiene que ser?
• Y mucho más.

Ahora expondré la mayoría de los puntos de fallo comunes cuando se construye una biblioteca de interfaz de usuario:

• No construir primero un sistema de diseño.
• No pensar en la entrega y distribución.
• No cuidar la API de los componentes.
• Crear componentes vinculados con el negocio.
• Equipo de UI aislado
• Utilizar las herramientas equivocadas

Sistema de diseño

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

Lamentablemente, siempre he trabajado en una aplicación existente con componentes y comportamientos complejos. Recorro cada área o módulo de la app y creo mi "Inventario de la interfaz".

Leer más sobre Interface Inventory.

El Inventario de la Interfaz nos ayuda a definir la base y la lista de los elementos más utilizados, las diferentes versiones de un mismo elemento de la interfaz de usuario, y a utilizar el diseño atómico para ayudar a componer fácilmente los componentes en el futuro.

Leer más sobre Diseño atómico

Entrega y distribución

Ten cuidado con la forma de distribuir y entregar tus componentes de autores y consumidores. Si sus componentes se acoplan y enlazan en un solo paquete como

bash
npm install @my_amazing_library

Para grandes componentes de negocios que utilizan componentes con diferentes hojas de ruta y características, un solo paquete no es un buen negocio. Obliga a actualizar todas las versiones del componente por la librería y los impactos a actualizar y no permite entregar una versión específica.

Dividir el componente y la versión nos ayuda a proporcionar una actualización pequeña e incremental, los conflictos de dependencia redundante, el rendimiento y la estabilidad, sin forzar la actualización de todo si no lo necesita.

``bash
componentes
   ├─ grid-footer 5.1.1
   ├─ grid-action-button 1.1.0
   ├─ grid-header 3.7.6

API de componentes y flexibilidad

La construcción de una API de componentes con flexibilidad está relacionada con el "Equipo de IU aislado", pero tenemos que tener en cuenta quién utiliza nuestros componentes.

Una solución es escribir un borrador antes de codificar, o pensar en cómo otros usan nuestros componentes nos permite escribir una API semántica.

Entender el contexto ayuda a crear un componente claro y semántico como

<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, ayudar a compartir el estado del componente rápidamente, y reducir la cantidad de inyectar cosas para la comunicación.

Leer más sobre exportAs

Considerar la usabilidad y la composición en nuestros componentes; permitir componentes hijos con <ng-content></ng-content> y construir componentes compuestos.

Leer más sobre Componentes compuestos.

Ten en cuenta que el objetivo principal es la flexibilidad para proporcionar componentes funcionales.

Equipo UI

Soy un gran fan de la NBA, y ten en cuenta que  dos jugadores pueden ganar partidos, pero con un equipo que trabaje junto con anillos.   El equipo de UI necesita trabajar con toda la compañía, no codificar solo o aislado. La biblioteca de componentes es para la empresa, no para el Equipo de IU.

Un equipo se centra solamente en la biblioteca de interfaz de usuario sin compartir y obtener retroalimentación de sus clientes (los otros desarrolladores o productos que lo utilizan); hacer una biblioteca sin escenarios o problemas reales de la empresa.

Ten en cuenta los siguientes puntos:

• La UI Library debe estar abierta para que otros desarrolladores o representantes del equipo puedan publicar o promocionar componentes.
• Comparta los conocimientos de los nuevos miembros con directrices para publicar componentes.
• Construya su equipo de interfaz de usuario con un representante de cada producto o módulo.

Utilizar las herramientas adecuadas

Angular tiene algunas opciones para construir nuestra librería de UI; el CLI de Angular soporta múltiples proyectos de trabajo para dividir el código en varios paquetes, pero no es suficiente.

• ¿Cómo se gestionan los múltiples proyectos?
• ¿Cómo comunica el equipo de UI los componentes?
• ¿Qué pasa con las pruebas?
• ¿Y qué hay de mantener las bibliotecas actualizadas?

No quiero decirte la "solución de oro", o la "bala de plata", y las siguientes herramientas son mi recomendación:

• Angular: angular.io ¡Mi precioso framework de JavaScript! :)
• Nx: Gran nx.dev Gran herramienta para monorepo todo el código en un solo lugar con consistencia y fácil gestión de dependencias.
• StoryBook: Simplifica la caja de arena para otros desarrolladores y la empresa para jugar con los componentes de la interfaz de usuario con la documentación y los casos de usuario (Historias) fácil. storybook.js.org
• Cypress: cypress.io cubre las pruebas de componentes de e2e y cypress y prueba tus componentes rápidamente.
• Jest: jestjs.io Prueba de unidad para servicios y negocios.

Resumen

La creación de una biblioteca de interfaz de usuario es una gran responsabilidad. Tómese su tiempo antes de empezar y los requisitos de la empresa.

Una biblioteca de UI es una inversión de tiempo y recursos para la empresa, pero el ROY es más que el código. Hace que el desarrollador sea rápido y fácil de acelerar el desarrollo.

Tal vez me olvide de algo más. Si quieres añadir algo, por favor deja un comentario.