RunRun: Styles & Components
La experiencia de desarrollar nuestras propias librerías y documentarlas con Storybook.
En Flux IT tenemos una aplicación desarrollada in-house llamada RunRun, que nos permite mantener la comunicación y gestionar distintos aspectos de nuestra vida dentro de la empresa. Tras cuatro años, llegó un momento en que RunRun resultó en una aplicación monolítica, hecha en muchas etapas y por muchas manos, con un bootstrap customizado y sobrescrito y componentes de varios lados, a veces con funcionalidades similares, para obtener los resultados que se buscaban.
Cuando empezamos a planear migrar de Angular.js a React y aprovechar a modularizar las funcionalidades más importantes en distintas aplicaciones, nos propusimos, a su vez, crear un template en React que usara unas librerías de estilos y componentes propias, con el objetivo inicial de agilizar cada nuevo desarrollo y mantener la consistencia entre cada una de estas nuevas aplicaciones.
Te invito a seguir la lectura de este artículo para conocer los pasos que recorrimos y que pueden serte útiles al momento de crear, documentar y usar estas librerías, y los beneficios que nos brindan.
¿Cómo pensar en el armado de una librería de estilos y componentes?
En primer lugar, conviene definir nuestros design tokens o variables: cuál será la paleta de colores, fuentes, tamaños tipográficos y efectos, es decir, las propiedades recurrentes y por defecto que tendrá nuestra aplicación. Con esto ya definido, en nuestra librería de estilos pudimos crear un reset para dar la apariencia inicial básica a las aplicaciones y disponibilizar el set de variables que usaríamos al momento de desarrollar los componentes.
En segundo lugar, acudimos a atomic design, una metodología que se viene nombrando desde hace años y nos plantea pensar en los elementos que componen la vista de una aplicación como átomos, moléculas y organismos; en definitiva, como pequeñas piezas que se pueden ir combinando para crear los distintos componentes necesarios en una pantalla. Esta es una excelente forma de pensar cómo trabajar nuestros componentes: empezando por los más pequeños e ir creciendo en combinaciones cada vez más complejas.
Si contamos con vistas o páginas ya armadas, se pueden ir desmenuzando para llegar a determinar los distintos elementos en uso y luego organizarlos. Si hace falta, cuando detectamos demasiadas variantes y veamos que podemos reducirlas, podemos modificar estos elementos para tener mayor consistencia visual.
En el caso de que se trate de una aplicación completamente nueva, lo mejor es trabajar codo a codo entre diseño y desarrollo para definir en conjunto, durante las etapas iniciales, cuáles serán los design tokens, los componentes, sus variaciones y usos. A la vez, es importante cuidar los acuerdos entre ambos equipos respecto de las nomenclaturas que usaremos para identificar cada componente y sus propiedades, para evitar tener diferencias que puedan complicar el trabajo al inspeccionar el archivo de diseño a la hora de desarrollar las vistas de la aplicación usando nuestra librería.
¿Qué usamos para documentar las librerías?
Para documentar nuestras librerías, elegimos Storybook, que además de permitirnos mostrar de forma aislada cada componente y dar información de cuándo y cómo usarlo, permite agregar un playground para probar cómo responde a sus distintas propiedades, consultar y copiar su código, así como buscar y visualizar los componentes en distintos contextos cambiando el fondo o tamaño de su preview. Y no es algo que usamos sólo para consumir documentación: Storybook sirve, inclusive, cuando estamos desarrollando un componente nuevo para la librería, como un entorno donde ir viendo y probando el resultado.
Al momento de documentar, es sumamente útil pensar en las experiencias que hemos tenido consultando otras librerías, para así tomar las prácticas que más convenga usar en nuestro caso, teniendo en cuenta cómo organizarla, cómo mostrar las variantes de nuestro componente, cómo redactar o mostrar los “dos” y los “don’ts”, etc. Personalmente, habiendo trabajado unos cuantos años con Bootstrap y Material Design, estas fueron fuertes influencias al momento de definir cómo estructurar varios elementos y su documentación.
¿Cómo usamos nuestras librerías?
Para usar nuestras librerías, disponibilizamos internamente unos packages de npm que forman parte de las dependencias en el template de React a partir del que creamos nuestras aplicaciones. La documentación hecha usando Storybook puede ser consultada de la misma forma que en cualquier otro framework UI, al estar disponible desde uno de nuestros servidores.
La librería de estilos hace que se aplique un restyling inicial, pero no es su única función: al estar hecha con Sass, nos permite usar algunos de sus archivos como módulos que exponen variables, mixins y funciones que podemos usar al momento de crear componentes exclusivos dentro de la aplicación que estemos desarrollando, y que nos ayudan a mantener el sistema visual.
¿Cuáles son los beneficios de tener nuestra propia librería?
Crear nuestra propia librería de estilos y componentes UI sin duda implica esfuerzo, al requerir dedicación del equipo para mantenerla y usarla según los estándares que definimos, pero se compensa al agilizar el comienzo de una nueva aplicación, sabiendo que ya contaremos con una base; y es especialmente útil cuando queremos tener más control sobre cómo será la apariencia y el funcionamiento de nuestro producto final en todo su conjunto. A su vez, si nuestro producto tiene un cambio identitario, será siempre mucho más fácil modificar las variables y los componentes de alto nivel, que ir vista por vista haciendo los cambios necesarios.
Incluso si no desarrollamos una librería propia, tal vez usar otro framework para desarrollar nuevos componentes más complejos puede requerir documentarlos, y usar Storybook para hacerlo también puede ser muy útil.
Este año nos encuentra reformulando la aplicación para la que creamos estas librerías de estilos y componentes. Habiendo vivido las ventajas de tener estas dependencias propias, apostamos a mantenerlas, por lo que nos encontramos en la tarea de hacer su versión 2 para acompañar los cambios que exige esta evolución y con la posibilidad de introducir nuevas mejoras a partir de todos nuestros últimos aprendizajes.
