Medición de la Cobertura del Sistema de Diseño React

Hola, mi nombre es Karen. Actualmente trabajo en una startup llamada Fabric. Es una startup de comercio electrónico con sede en EE. UU. Anteriormente trabajé con Razorpay y Ripple Foods en India. Tengo un total de más de seis años de experiencia en el dominio de front-end.

Así que hoy estaré hablando sobre cómo medir la cobertura de un sistema de design. Para darles un poco de contexto sobre lo que es nuestro producto actual, está construido utilizando la arquitectura de micro front-end architecture. Usamos singles para React, Apps Script, y componentes de estilo. Entonces, como pueden ver en la parte del encabezado, hay diferentes productos, cada uno es un micro front-end diferente y tiene diferentes tipos de productos como gestión de productos, gestión de pedidos, gestión de cupones, gestión de clientes. Así es como se ve el producto.

Así que estábamos construyendo un sistema de design en TypeScript desde cero. Teníamos nuestro antiguo sistema de design DS 3.0 en JavaScript. Así que cuando migramos al sistema de design 4.0, que es nuestro nuevo sistema de design, queríamos medir nuestra cobertura. Así que la declaración del problema parecía algo así. Queríamos medir cuáles son los componentes DS 3 como cuál es el uso del componente del sistema de design antiguo y el uso del componente del nuevo sistema de design 4.0. Elementos HTML nativos que se estaban utilizando en nuestras aplicaciones y cualquiera de los componentes de estilo que se estaban utilizando. Y el último punto extra es describir su ruta de página en una estructura de árbol utilizando nuestros componentes.

Entonces, cada vez que tenemos algún problema lo que generalmente hacemos es buscarlo en Google. Y luché en Google para encontrar una solución. Luego aterricé en este hermoso paquete de NPM llamado React Scanner. Básicamente, React Scanner es un paquete de NPM que puede analizar estáticamente su código y puede extraer los detalles de su componente incluyendo sus props y todo. Así que para entrar en detalles he creado este componente React de muestra. Aquí pueden ver en el componente de la aplicación que estamos utilizando algún contenedor de proveedor y tenemos texto y tenemos el componente de enlace aquí. Así que aquí pueden ver que el React Scanner puede generar como salida en algunos formatos diferentes. Uno de ellos es la salida en bruto. Así que para la salida en bruto da como todos los detalles de una instancia en particular. Así que en base al proveedor tendrá una matriz de instancias. Así que en la primera instancia tiene como información de importación de dónde estamos importando este componente sus props y dónde está en el archivo. Y en la salida procesada aquí pueden ver que tiene como información procesada o acumulativa como cuál es el número de instancias del componente de texto, sus props, y todo lo que pueden ver aquí. Entonces, ¿cómo funciona React Scanner? Así que React Scanner, lo que hace es que lee el archivo y luego analiza el código en AST básicamente árbol de sintaxis abstracta.

Es una representación en árbol de su código. Y luego recorre el AST y recopila la información como el nombre del componente, información de importación, información de prop, data. Como recopila data y luego la devuelve en formato JSON. Entonces, usando esos data, pudimos generar este hermoso panel de control que pueden ver aquí. Podemos ver para esta aplicación en particular Copilot MFA admin. Estábamos usando tantos componentes DS3 y tantos componentes DS4 y el número de instancias de cada uno de los componentes también lo podemos ver aquí.

Entonces, la primera parte de nuestro problema se resolvió pero aún necesitábamos resolver algunos puntos como elementos nativos HTML, componentes de estilo, estructura de componentes y anti-patterns. Entonces, lo primero que hicimos fue hacer un fork del repositorio de React Scanner y ahora estamos manteniendo una copia del scanner en nuestra base de código. Entonces, identificar elementos nativos HTML es una tarea muy sencilla. Solo necesitas leer el nombre de los elementos JSX y necesitas verificar si es un elemento en minúsculas y no debería contener ningún punto. Si se cumplen estas dos condiciones entonces puedes decir que este componente JSX es un elemento HTML. Entonces, basándonos en estas condiciones pudimos identificar aquí pueden ver que pude identificar la etiqueta A, H1 y P en estos archivos.

La siguiente parte difícil fue identificar los componentes de estilo. Entonces, estos componentes de estilo no estaban en el paquete de React Scanner. Entonces, tuvimos que construir por nuestra cuenta escribiendo un script personalizado. Entonces, pueden ver que podemos declarar los componentes de estilo en dos estilos de código separados. Aquí pueden ver que estamos usando style dot button y estamos usando la función de estilo en el botón base. Entonces, esta sintaxis se llama literales de plantilla de etiquetas. Entonces, aquí está el código que devolvemos para identificar los componentes de estilo. Entonces, básicamente queríamos identificar de dónde se construyó este botón base, como si se construyó sobre algún componente existente o algún elemento HTML. Aquí pueden ver que este botón base se construyó sobre el botón, pero este botón primario se construyó sobre el botón base. Entonces, usando este script, no solo el nombre del componente, sino que también pudimos recopilar el CSS en bruto que se escribieron en las aplicaciones. Entonces, aquí pueden ver que estamos recopilando CSS en bruto de estilo y ruta de archivo. Y el estilo de básicamente contiene de dónde se construyó el componente de estilo. Y la última parte son los anti-patterns. Entonces, los anti-patterns es un término que describe cómo no resolver tus problemas recurrentes. Entonces, ¿qué anti-patterns podríamos tener en términos de consumo del sistema de design es que algunos de los ejemplos podrían ser como usar un color codificado en lugar de nuestro token del sistema de design o como usar un ancla o entrada o botón. Elemento HTML, en lugar de usarlo desde nuestro sistema de design. Entonces, estos son algunos de los anti-patterns que queríamos identificar. Entonces, usando toda esta información que obtuvimos de este scanner, pudimos mostrar esa información en nuestro panel de control.

Aquí pueden ver que los componentes de entrada estaban obteniendo entrada como elementos HTML que se estaban utilizando o un componente de estilo se estaba utilizando en siete fases. Así que estamos dando la sugerencia al equipo de dominio de que deberían usar la entrada del sistema de design. De manera similar para el botón y para el componente de enlace también. Para los componentes de estilo aquí pueden ver que pudimos identificar algunas estadísticas interesantes. Pueden ver que en este componente en particular, estábamos usando el color codificado que no queremos hacer. Queremos que utilicen el color para confirmar el sistema de design. Así que esa información pudimos recopilar.

Por último, pero no menos importante, está la reestructuración de componentes. Básicamente para darles una idea más de cómo puede verse una reestructuración de componentes, aquí pueden ver que esta página de gestión de usuarios se ha dividido en múltiples nodos, por lo que cada nodo representa un componente y si es un componente compuesto, entonces está en gris y podemos expandirlo aún más. Así que aquí pueden ver que este formulario de usuario tiene múltiples componentes como desplegable, entrada, entrada, botón de icono de entrada. Así que desde este gráfico, pueden ver que ya podemos identificar un anti-patrón aquí. Aquí pueden ver que estamos usando tres instancias de barra de pila en esta ruta en particular en el nivel superior que no deberíamos estar haciendo. En realidad, deberíamos estar usando solo una barra de pila con diferentes props. Así que esta estructura de árbol básicamente te dará una idea de todos los componentes utilizados a nivel de ruta y puedes obtener los insights, cómo o qué se puede optimizar. Planeamos agregar muchas más características en esta estructura de árbol, básicamente agregando los detalles de prop y resaltando un sistema de design diferente o diferentes componentes de diferentes bibliotecas utilizando diferentes colores para que sea visualmente muy claro de qué está hecha toda esta página. Así que sí, eso es prácticamente todo.

Así que en resumen, utilizando toda esta información pudimos obtener la idea general de cómo se consume nuestro sistema de design. Usando estos data pudimos tomar decisiones basadas en data en torno a cualquier componente importante como si el componente, como cuánto se usa. Como si el componente se usa en lugares importantes tomaríamos como, hacerlos compatibles con versiones anteriores y queremos apoyar eso o como no queremos romper esos componentes muy frecuentemente o hacer un experimento en los componentes más utilizados o ser muy cuidadosos con eso. Y también pudimos resaltar los anti patterns utilizando el escáner React. Eso es prácticamente todo. Si quieren aprender más sobre el escáner React visiten este enlace. Y sí, si están en Twitter o LinkedIn no duden en conectarse. Gracias.