Desarrollo y Fomento de Bibliotecas de Componentes

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

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.

¡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

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

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

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.