Video Summary and Transcription
La charla de hoy analiza la importancia de una buena API de componentes y el equilibrio entre rigidez y flexibilidad. La demostración muestra la evolución gradual de la configurabilidad de un componente manteniendo la facilidad de uso. Medir la efectividad de una biblioteca de componentes implica factores como la tasa de adopción y la cobertura de componentes. Recopilar datos y aceptar cambios disruptivos son cruciales para la mejora continua. Asegurarse de que los consumidores estén actualizados y a la vanguardia es responsabilidad del proveedor de la biblioteca.
1. Introducción a la API de Componentes
Hoy hablaremos sobre lo que hace que una buena API de componentes. La API es el aspecto más importante de una biblioteca de componentes. Puede ser rígida o flexible, y cada una tiene sus ventajas. Una API rígida es fácil de usar y garantiza resultados consistentes. También es más fácil de implementar. Ahora profundicemos en los detalles.
Hola a todos, soy Lachlan y hoy, junto con mi colega Logan, les hablaremos sobre el desarrollo y la adopción de bibliotecas de componentes. Esto se dividirá en dos partes. Primero, hablaré sobre lo que hace que una buena API de componentes y segundo, Logan hablará sobre cómo medimos el éxito de nuestra propia biblioteca de componentes y cómo utilizamos datos para mejorarla aún más para nuestros usuarios. Una breve introducción, soy líder técnico en TikTok trabajando en los sistemas de diseño y soy responsable de mantener nuestra biblioteca de componentes interna llamada Tux. Por lo tanto, paso mucho tiempo pensando en bibliotecas de componentes y cómo nuestros usuarios interactúan con ellas. Así que primero me pregunto qué hace que una buena biblioteca de componentes y desde mi punto de vista, la API es sin duda lo más importante. Es la forma en que los desarrolladores interactúan con la biblioteca. Entonces, ¿qué hace que una buena API de componentes? He descubierto que las APIs se encuentran en un espectro que va desde lo rígido hasta lo flexible. Si imaginamos un componente de interfaz de usuario, por ejemplo, un selector de fechas, si le damos una API rígida, esto tiene algunas ventajas. Una de ellas es que si es rígido y solo hay algunas formas en las que se puede utilizar, generalmente es muy fácil de usar porque hay muy pocas formas en las que se puede utilizar de manera incorrecta. En segundo lugar, tiene resultados consistentes, lo que significa que si varios equipos están utilizando este componente, es muy probable que lo estén utilizando de la misma manera y obtendrán el mismo aspecto y sensación en los diferentes productos. En tercer lugar, y de manera algo egoísta, es mucho más fácil implementar una biblioteca que tenga una API rígida
2. Enfoque del Diseño de la API
Nuestro objetivo es cubrir el 90% común de los casos de uso con una API rígida, centrándonos en resolver problemas difíciles como la accesibilidad y la animación. Reconocemos que no podemos cubrir el 100% de los casos de uso, por lo que hacemos que el 10% restante sea fácil de manejar para los equipos. Si nos encontramos con un caso de uso que no podemos admitir, podemos considerar abrir la API, pero esto puede introducir cambios que rompen la compatibilidad y afectan la consistencia y complejidad de la biblioteca.
Comparado con uno que sea verdaderamente genérico. En el otro extremo, podrías construir un selector de fechas de una manera muy flexible. Y eso cubriría más casos de uso. Esto también es realmente importante porque si un componente no se ajusta a las necesidades de un usuario, es posible que tengan que construir el suyo propio o obtener uno de código abierto. Y tan pronto como hagan eso, potencialmente estarías sacrificando la apariencia y sensación consistentes que estás tratando de lograr a través de tener una API rígida. Por lo tanto, nuestro enfoque es reconocer que no necesitas y no puedes cubrir realmente el 100% de los casos de uso. Por lo tanto, en lugar de eso, apuntamos al 90% común e intentamos hacer que el 10% restante sea fácil para que los equipos lo hagan por sí mismos. Por lo tanto, comenzamos cerca de la izquierda del espectro con una API realmente rígida que se centra en resolver los problemas difíciles. Por ejemplo, características de accesibilidad y animación. Llamo a estos problemas difíciles porque la mayoría de los desarrolladores front-end no tienen experiencia en resolver estos problemas y preferirían pasar su tiempo trabajando en cosas como la lógica de la aplicación. Nos movemos más hacia la derecha a medida que sea necesario. Si nos encontramos con un caso de uso realmente bueno que no podemos admitir con nuestra API actual, consideraremos abrir un poco la API. Pero esto puede implicar cambios que rompen la compatibilidad, de los cuales Logan hablará más tarde. También debemos tener cuidado porque moverse hacia la derecha significa que estamos
3. Demo of Component API
Ahora me gustaría hacer una demostración de cómo podemos tomar un componente muy simple con una API muy rígida y gradualmente hacerlo más configurable sin hacer demasiados sacrificios en cuanto a su facilidad de uso y proporcionar una apariencia y sensación consistentes. Pasemos a la AV2 de nuestro componente. Esta es una forma de abordar el problema. Como puedes ver aquí, las props son prácticamente las mismas que en la V1, pero los elementos adicionalmente toman una prop opcional de etiqueta, que puede transmitir prácticamente lo que necesites. Por supuesto, podríamos complicar más este tipo. Podrías configurar todo acerca de las etiquetas y podrías proporcionar más de una, pero esto realmente solo satisface las necesidades de un equipo de producto, y si hay 10 o más equipos de producto, cada uno con diferentes requisitos, esto se volverá realmente complicado y tal vez difícil de usar. Entonces, tal vez haya una mejor manera de hacer esto. Pasemos a la versión 3 de nuestro componente. Y esto utiliza una API que usamos mucho internamente en TikTok en nuestras bibliotecas.
Potencialmente reduciendo la consistencia y aumentando la complejidad de la biblioteca en sí. Ahora me gustaría hacer una demostración de cómo podemos tomar un componente muy simple con una API muy rígida y gradualmente hacerlo más configurable sin hacer demasiados sacrificios en cuanto a su facilidad de uso y proporcionar una apariencia y sensación consistentes. Entonces, aquí en el lado derecho tenemos un componente de demostración, que es un ListBox desplegable, que estoy seguro de que todos ustedes han visto antes, y echemos un vistazo a la API. Como puedes ver en el lado izquierdo, aquí están las props que toma nuestro ListBox v1, e importante, toma algo llamado items, que como puedes ver aquí arriba, es una matriz de lo que llamamos elementos de lista. Y pueden tener una etiqueta y un valor y opcionalmente estar deshabilitados. Como puedes ver, esto es bastante fácil de usar, pero realmente no puedes configurar nada al respecto, especialmente cómo se ve. Imagina que tenemos un equipo de producto que tiene este selector de sabores, y tal vez quieran explicar al usuario por qué cierto elemento está deshabilitado. Tal vez este elemento está agotado y quieren transmitir eso al usuario de alguna manera en lugar de simplemente deshabilitarlo u ocultarlo. Entonces pasemos a la AV2 de nuestro componente. Esta es una forma de abordar el problema. OK. Como puedes ver aquí, las props son prácticamente las mismas que en la V1, pero los elementos adicionalmente toman una prop opcional de etiqueta, que puede transmitir prácticamente lo que necesites. Como puedes ver a la derecha, ahora podemos marcar un elemento como agotado, tal vez marcar un elemento como nuevo, y esto es realmente bueno. Pero ¿qué pasa si el equipo necesita que un elemento tenga más de una etiqueta? Un elemento podría ser nuevo y también estar agotado, o un elemento podría ser popular y nuevo. O tal vez queremos cambiar el color de estas etiquetas para que sean más identificables. Por ejemplo, el verde podría significar algún tipo de connotación positiva, tal vez se use para elementos nuevos, mientras que el rojo podría ser negativo, se use para elementos agotados. Por supuesto, podríamos complicar más este tipo. Podrías configurar todo acerca de las etiquetas y podrías proporcionar más de una, pero esto realmente solo satisface las necesidades de un equipo de producto, y si hay 10 o más equipos de producto, cada uno con diferentes requisitos, esto se volverá realmente complicado y tal vez difícil de usar. Entonces, tal vez haya una mejor manera de hacer esto. Pasemos a la versión 3 de nuestro componente. Y esto utiliza una API que usamos mucho internamente en TikTok en nuestras bibliotecas. Así que la versión 3 de nuestro ListBox todavía toma la misma matriz de elementos, pero ahora toma dos propiedades adicionales. Render button y render item. Es posible que reconozcas este patrón como render props. Lo encontramos realmente útil. Así que aquí configuremos cómo se renderiza el botón. Mm-hmm. Y básicamente esta es la forma más sencilla de usar el componente. Pero lo genial de esto es que los elementos son de tipo genérico. Por lo tanto, puedes agregar prácticamente cualquier dato a estos elementos, y luego usarlo dentro del método de renderizado para obtener elementos de lista realmente configurables. Voy a copiar un ejemplo que hice antes para mostrarte a qué me refiero.
4. Composing Components and API Design
Hemos agregado propiedades adicionales al componente de lista para mostrar condicionalmente etiquetas. Esto permite una apariencia y sensación más consistentes en los componentes. La inferencia de tipo genérico facilita la adición de nuevas propiedades. Otro ejemplo es una lista de empleados con imágenes de avatar e indicadores de conexión en línea y fuera de línea. Esto demuestra cómo nuestras APIs equilibran la facilidad de uso, la consistencia y la configurabilidad.
De acuerdo. Entonces puedes ver aquí, además de la etiqueta y el valor, ahora hemos agregado las propiedades adicionales de es nuevo y está agotado. Y nuestro método de renderizado no solo muestra la etiqueta, sino que también verifica si el elemento es nuevo o si el elemento está agotado y muestra condicionalmente una etiqueta. Esta etiqueta es en realidad otro componente en nuestra component library. Así que es genial que estemos componiendo componentes ya existentes con esta lista. Entonces tal vez podamos obtener una apariencia y sensación más consistentes en cada uno de nuestros componentes. Así que echemos un vistazo a cómo se ve. Genial. Esto es bastante bueno. Y nuevamente, debido a que es un tipo genérico, el equipo de producto puede agregar más propiedades según sea necesario. Entonces tal vez tengamos popular en uno de estos. Tal vez el plátano sea popular. Genial. Y tal vez, si es popular, podríamos agregar una etiqueta de popular. Y puedes ver que la inferencia de tipo es excelente porque es un tipo genérico. Así que es realmente útil. De acuerdo, sí, tenemos un elemento popular. Muy bien. Mostraré otro ejemplo, tal vez un equipo de producto necesita tener una lista de empleados. Y realmente necesitan etiquetas, tal vez necesitan algo como una imagen de avatar para mostrar cómo se ve el empleado, o incluso un indicador de conexión en línea y fuera de línea. Así que permíteme mostrar un ejemplo que hice antes. Y puedes ver nuevamente, nuestros elementos básicamente ahora tienen un avatar y un estado de conexión en línea. Y en el método de renderizado, si observamos el método de renderizado de los elementos, también estamos agregando opcionalmente un avatar. Y nuevamente, este es un componente de nuestra component library que estamos usando. Así que es realmente agradable, podemos componer cosas de esta manera. Entonces, si miras a la derecha, podemos marcar a los empleados como en línea. E incluso podemos mostrarlos dentro del botón del selector. Como puedes ver aquí arriba. Entonces, este es un ejemplo de cómo design nuestras APIs para tratar de encontrar un equilibrio entre la facilidad de uso, la consistencia y permitir cierta configurabilidad. Ahora se lo paso a Logan.
5. Measuring Component Library Effectiveness
Discutiré cómo medir la efectividad de una biblioteca de componentes considerando factores como flexibilidad, rigidez, unidad de marca, productividad del desarrollador y calidad del código. Una de las principales heurísticas que utilizamos es la tasa de adopción, que mide cuánto los ingenieros desean utilizar nuestros componentes. Si los componentes no son lo suficientemente flexibles, los desarrolladores pueden tener que construir los suyos propios, lo que supone una pérdida de tiempo y una disminución de la tasa de adopción. Por otro lado, si la biblioteca es demasiado rígida y complicada, también puede obstaculizar la adopción.
¡Hola a todos! Soy Logan Rolston, un ingeniero de software en TikTok, y seré el encargado de la segunda parte de esta charla hoy. Lachlan ya les habló sobre los factores y equilibrios que debemos considerar para designar una buena biblioteca de componentes. Y yo continuaré abordando la siguiente pregunta relevante. ¿Cómo se cuantifican las métricas para medir la efectividad de su biblioteca de componentes? Repasaremos cómo recopilar estas métricas sobre cómo se utiliza su biblioteca de componentes en la práctica, y luego hablaremos sobre cómo utilizamos estos datos para tomar decisiones y evolucionar nuestras APIs de componentes en TikTok.
Entonces, una breve introducción sobre mí. Soy Logan. Trabajo en la biblioteca de componentes Tux, que es la biblioteca de UI interna de TikTok. Y parte de mi trabajo se centra en la infraestructura que rodea a los sistemas de designar, como herramientas de análisis de código estático, como hablaremos en un momento. Linting, code mod, y cosas por el estilo. Así que comencemos con cómo medir la efectividad de una biblioteca de componentes. Cuando Lachlan habló sobre lo que hace que una biblioteca de componentes sea buena. Hizo referencia a un par de cantidades abstractas. Flexibilidad y rigidez. Que podemos describir en términos de una biblioteca de componentes. También está la unidad de marca, la productividad del desarrollador y una mejora en la calidad del código. Estas son todas cosas que queremos optimizar. Queremos tener una alta productividad del desarrollador, una alta calidad del código, obviamente. Pero son difíciles de medir en la práctica porque pueden ser bastante abstractas. Entonces, cuando se trata de encontrar heurísticas que podamos usar para representarlas, una de las principales que utilizamos es la tasa de adopción. La tasa de adopción es realmente importante porque mide cuánto un ingeniero realmente desea utilizar tus componentes. Porque digamos que tus componentes no son lo suficientemente flexibles. Entonces, digamos que tienes un campo de entrada de texto y no tiene un estado de texto no válido. Por ejemplo, digamos que ingresaron una contraseña con muy pocos caracteres o algún dato del formulario es incorrecto o un correo electrónico no está en el formato correcto o algo así. Quieres que tenga un borde rojo alrededor y un mensaje de error debajo. Digamos que no tienes eso. Entonces el desarrollador tendrá que construir su propio componente, lo cual será una gran pérdida de tiempo para el desarrollador. Y también disminuirá tu tasa de adopción. Y de manera similar, si tu biblioteca de componentes no es lo suficientemente rígida, será demasiado
6. Medición de la Tasa de Adopción
La tasa de adopción es una heurística primaria para medir la efectividad de una biblioteca de componentes. La cobertura de componentes, que calcula la proporción de uso del componente correcto respecto al total de casos, es una de las métricas principales que utilizamos. Por ejemplo, si un archivo utiliza el botón de Tux tres veces y una combinación de mi propio botón y una etiqueta de ancla con el nombre de clase 'btn-primary' nueve veces, la cobertura del componente de Tux en ese archivo sería del 25%. Aunque determinar con precisión el número de casos buenos y malos es un desafío, sigue siendo una heurística confiable.
demasiado complicado, hay demasiadas opciones. Los desarrolladores se pierden en una maraña de diversas configuraciones, y al final no utilizarán realmente tu componente y tu tasa de adopción también disminuirá. Por lo tanto, la tasa de adopción es una heurística primaria. Sabemos que si aumenta, estamos haciendo algo bien. Hay varias formas de medir la tasa de adopción, pero una de las principales que utilizamos es la cobertura de componentes. La cobertura de componentes es simplemente la proporción de veces que alguien utiliza uno de tus componentes respecto al número de veces que deberían estar utilizando tus componentes. Llamamos a las veces que realmente utilizan tus componentes casos buenos. Por ejemplo, tomemos el botón de Tux, nuestro componente de botón, aquí. Cada vez que utilizan el elemento JSX 'tux button' en el archivo, eso es un caso bueno. Están haciendo algo bien. Están utilizando el componente correcto. Y cada vez que utilizan algo como mi propio botón o una etiqueta de ancla con el nombre de clase 'btn-primary', eso probablemente será un caso malo. Deberían estar utilizando el botón de Tux en su lugar. Y supongamos que en un archivo de código fuente, utilizan el botón de Tux tres veces y utilizan una combinación de mi propio botón y una etiqueta de ancla con el nombre de clase 'btn-primary' nueve veces. Entonces diremos que en este archivo, el botón de Tux tiene una cobertura de componente del 25% porque son tres casos buenos de un total de 12 casos, es decir, tres de 12, 25%. Ahora, una cosa a tener en cuenta aquí es que, bueno, es posible determinar con precisión el número de casos buenos por completo. Los casos malos son en realidad un problema de inferencia de texto. Por lo tanto, la lógica aquí es un poco difusa, por lo que nunca se puede garantizar que los casos malos se calculen perfectamente. Pero eso dicho, sigue siendo una heurística muy precisa.
7. Métricas para la Biblioteca de Componentes
Podemos recopilar varias métricas para medir la tasa de adopción, la distribución de versiones, las tasas de adopción de estándares de estilo, las correcciones de errores o las solicitudes de funciones a lo largo del tiempo y las violaciones de reglas de lint relacionadas con la biblioteca de componentes.
De acuerdo, pero no estamos limitados solo a esas métricas. Podemos recopilar muchas más métricas. Por ejemplo, otra métrica para la tasa de adopción es hacerlo a nivel de repositorio, por lo que analizamos todas las bases de código que tenemos internamente. Decimos cuáles están utilizando TUX, y cuáles deberían estar utilizando TUX, y también podemos calcular una proporción de cobertura para eso. Podemos analizar la distribución de versiones, qué versiones están atrasadas en versiones antiguas de TUX y no están utilizando los componentes más actualizados. Eso es algo de interés. Podemos analizar las tasas de adopción de estándares de estilo. Por ejemplo, si estamos utilizando clases atómicas de TailwindCSS, ¿con qué frecuencia la gente realmente utiliza esas clases atómicas deCSS en comparación con estilos que son exactamente equivalentes y deberían ser reemplazados por esa clase atómica deCSS, para poder hacer cumplir cierta apariencia de estilo de código o unidad de marca, o cualquier otra construcción a través de aquí. Podemos analizar la tasa de correcciones de errores o solicitudes de funciones a lo largo del tiempo. Podemos analizar las violaciones de reglas de lint relacionadas con la biblioteca de componentes. Hay muchas más
8. Recopilación de datos y aceptación de cambios disruptivos
Recopilamos datos sobre cómo se utiliza Tux a través de TuxScanner, una herramienta de análisis estático de código. Analiza los archivos de código fuente en AST y evalúa métricas para generar puntuaciones. Estas puntuaciones proporcionan información sobre el uso de componentes y nos ayudan a realizar mejoras. En TikTok, aceptamos cambios disruptivos para mantenernos ágiles y evolucionar continuamente nuestra biblioteca de componentes. Simplificamos nuestra arquitectura y utilizamos un monorepo para facilitar este proceso.
métricas que son útiles de recopilar. Entonces, ¿cómo recopilamos realmente estos datos? La forma principal en que lo hacemos es a través de una herramienta llamada TuxScanner. TuxScanner es una herramienta de análisis de código estático que examina nuestros archivos individuales de código fuente sin ejecutarlos y mide cómo se utiliza Tux en la práctica y envía estos datos a una API para que podamos analizar cómo se utiliza Tux. Comenzamos con un archivo de código fuente, lo analizamos en un AST, que es solo una representación en forma de árbol del código fuente, y luego evaluamos un conjunto de métricas en ese AST, y eso nos dará puntuaciones. Por ejemplo, podría ser una cobertura de componentes del 80% antes, o tal vez se estén utilizando 12 componentes obsoletos, o algo similar a eso. Simplemente nos recopila un montón de puntuaciones, las conglomeramos todas juntas y las enviamos a la API para que podamos ver cómo se está utilizando Tux en todos nuestros archivos de código, y filtrar a lo largo del tiempo, por plataforma, por métrica, y demás. Para profundizar un poco más en cómo funciona el escáner. Comenzamos analizando los archivos de código fuente en AST, árboles de sintaxis abstracta, que es solo una representación en forma de árbol del código fuente, y muestra cómo se relacionan todas las construcciones del lenguaje. Por ejemplo, los elementos JSX relacionados con el atributo del nombre de la clase y tienen un árbol basado en eso. Y esto nos permite evaluar un conjunto de métricas en ellos. Entonces, una métrica es solo una función que toma un conjunto de AST, los recorre y produce un conjunto de puntuaciones. Y la puntuación es simplemente el número de casos buenos, las cosas que estamos haciendo bien, el número de casos malos, las cosas que estamos haciendo mal y que necesitamos mejorar para mejorar nuestra puntuación. Los sitios de llamada de los casos buenos y malos, que son solo los enlaces a los nodos, generalmente son elementos JSX, pero también podrían ser una declaración de importación o algo en el código donde algo está saliendo mal. Y luego la fuente de cobertura, y luego lo conglomeramos todo juntos, lo enviamos a la API para que podamos filtrar por tiempo, por paquete y demás.
De acuerdo, ahora que TuckScanner ha recopilado todos estos datos, ¿cómo los utilizamos? Entonces, en TikTok, las cosas crecen rápidamente, y nuestra biblioteca de componentes no es una excepción. Necesitamos poder evolucionar rápidamente para mantenernos al día con la rápida tasa de cambio. Y queremos poder hacer eso para mantenernos ágiles y seguir evolucionando. Entonces, necesitamos poder mantener lo que funciona y desechar y rehacer lo que no funciona. Ahora, esto es una buena verdad para cómo se debe mantener el código, pero no se practica a menudo. Y eso se debe a que introducir todos estos cambios disruptivos todo el tiempo no es divertido para los desarrolladores. Les dificulta la vida e introduce mucho mantenimiento. Pero no podemos ver estas cosas como una carga de mantenimiento. Siempre debemos esforzarnos por introducir cambios disruptivos para alcanzar esa forma platónica asintótica de lo que debería ser una biblioteca de componentes, y no podemos abandonar eso por el bien de la estabilidad. Debemos mantenernos ágiles. Entonces no debemos tener miedo de introducir cambios disruptivos en nuestros componentes. De hecho, queremos hacerlos regularmente. Debemos aceptar los cambios disruptivos. Esto es fácil de decir en teoría, pero difícil de hacer en la práctica. Y en TikTok, hemos hecho un esfuerzo concentrado para simplificar nuestra arquitectura y facilitar esto. Un ejemplo de ello es el uso de un monorepo. Y en un monorepo, casi todos nuestros consumidores son
9. Actualizaciones para los Consumidores y Evolución de la Biblioteca
Los consumidores no deben quedarse atrás al introducir cambios disruptivos. Es nuestra responsabilidad en Tux actualizar a nuestros consumidores y asegurarnos de que estén a la vanguardia. Discutimos qué hace que una buena biblioteca, cómo cuantificar su efectividad y cómo utilizar los datos para evolucionarla.
en la última versión de Tux. Y esto significa que los consumidores no se quedan atrás. Porque digamos que introducimos una serie de cambios disruptivos y lanzamos la versión 5 o cualquier otra de Tux, pero muchos consumidores están en la versión 3 porque no quieren pasar por una actualización con todos los nuevos cambios. Esto significa que en realidad no estamos practicando lo que predicamos, porque si las personas no están utilizando realmente tus nuevos componentes de vanguardia, entonces en la práctica, simplemente se están quedando atrás y fue algo inútil. Por lo tanto, esto significa que cada vez que introducimos una solicitud de extracción que introduce un cambio disruptivo como parte de eso, tenemos que ir y actualizar a la mayoría de nuestros consumidores para que utilicen la última versión de Tux. Porque la mayoría de nuestros consumidores siempre están en la última versión de Tux. Y esto significa una filosofía importante que debemos aplicar, que es la co-propiedad. En Tux, si hacemos un cambio disruptivo en nuestro paquete, es nuestra responsabilidad actualizar a nuestros consumidores. No es responsabilidad de los consumidores. Por lo tanto, debemos revisar todos los sitios de llamada para realizar modificaciones de código o lo que sea y asegurarnos de que estén a la vanguardia y que no se queden atrás.
De acuerdo. Un resumen rápido. Hablamos sobre qué hace que una buena biblioteca sea buena. Hablamos sobre cómo cuantificar la efectividad de una component library y hablamos sobre cómo utilizar esos datos para evolucionar tu biblioteca. Muchas gracias. Aprecio su participación.
React Advanced Conference 2021
React Day Berlin 2022
TechLead Conference 2023
React Summit 2023
React Summit US 2023
Vue.js London Live 2021
JSNation 2023
Node Congress 2024
Comments