¿Qué hace que una biblioteca de componentes sea buena? Para crear una biblioteca de componentes que las personas quieran usar, es necesario navegar entre la extensibilidad, la facilidad de uso y la consistencia de diseño. Esta charla cubrirá cómo abordar estos factores al construir una biblioteca de componentes en React, cómo medir su éxito y cómo mejorar las tasas de adopción.
Desarrollo y Fomento de Bibliotecas de Componentes
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.
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.
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.
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.
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.
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.