Desarrollo y Fomento de Bibliotecas de Componentes

Rate this content
Bookmark

¿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.

22 min
24 Oct, 2022

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.

Available in English

1. Introducción a la API de Componentes

Short description:

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

Short description:

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

Short description:

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

Short description:

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

Short description:

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

Short description:

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

Short description:

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

Short description:

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

Short description:

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.

Check out more articles and videos

We constantly think of articles and videos that might spark Git people interest / skill us up or help building a stellar career

React Advanced Conference 2021React Advanced Conference 2021
39 min
Don't Solve Problems, Eliminate Them
Top Content
Humans are natural problem solvers and we're good enough at it that we've survived over the centuries and become the dominant species of the planet. Because we're so good at it, we sometimes become problem seekers too–looking for problems we can solve. Those who most successfully accomplish their goals are the problem eliminators. Let's talk about the distinction between solving and eliminating problems with examples from inside and outside the coding world.
React Advanced Conference 2021React Advanced Conference 2021
47 min
Design Systems: Walking the Line Between Flexibility and Consistency
Top Content
Design systems aim to bring consistency to a brand's design and make the UI development productive. Component libraries with well-thought API can make this a breeze. But, sometimes an API choice can accidentally overstep and slow the team down! There's a balance there... somewhere. Let's explore some of the problems and possible creative solutions.
React Day Berlin 2022React Day Berlin 2022
22 min
Jotai Atoms Are Just Functions
Top Content
Jotai is a state management library. We have been developing it primarily for React, but it's conceptually not tied to React. It this talk, we will see how Jotai atoms work and learn about the mental model we should have. Atoms are framework-agnostic abstraction to represent states, and they are basically just functions. Understanding the atom abstraction will help designing and implementing states in your applications with Jotai
TechLead Conference 2023TechLead Conference 2023
35 min
A Framework for Managing Technical Debt
Let’s face it: technical debt is inevitable and rewriting your code every 6 months is not an option. Refactoring is a complex topic that doesn't have a one-size-fits-all solution. Frontend applications are particularly sensitive because of frequent requirements and user flows changes. New abstractions, updated patterns and cleaning up those old functions - it all sounds great on paper, but it often fails in practice: todos accumulate, tickets end up rotting in the backlog and legacy code crops up in every corner of your codebase. So a process of continuous refactoring is the only weapon you have against tech debt.In the past three years, I’ve been exploring different strategies and processes for refactoring code. In this talk I will describe the key components of a framework for tackling refactoring and I will share some of the learnings accumulated along the way. Hopefully, this will help you in your quest of improving the code quality of your codebases.

React Summit 2023React Summit 2023
24 min
Debugging JS
As developers, we spend much of our time debugging apps - often code we didn't even write. Sadly, few developers have ever been taught how to approach debugging - it's something most of us learn through painful experience.  The good news is you _can_ learn how to debug effectively, and there's several key techniques and tools you can use for debugging JS and React apps.
React Day Berlin 2022React Day Berlin 2022
29 min
Fighting Technical Debt With Continuous Refactoring
Top Content
Let’s face it: technical debt is inevitable and rewriting your code every 6 months is not an option. Refactoring is a complex topic that doesn't have a one-size-fits-all solution. Frontend applications are particularly sensitive because of frequent requirements and user flows changes. New abstractions, updated patterns and cleaning up those old functions - it all sounds great on paper, but it often fails in practice: todos accumulate, tickets end up rotting in the backlog and legacy code crops up in every corner of your codebase. So a process of continuous refactoring is the only weapon you have against tech debt. In the past three years, I’ve been exploring different strategies and processes for refactoring code. In this talk I will describe the key components of a framework for tackling refactoring and I will share some of the learnings accumulated along the way. Hopefully, this will help you in your quest of improving the code quality of your codebases.

Workshops on related topic

React Advanced Conference 2021React Advanced Conference 2021
174 min
React, TypeScript, and TDD
Top Content
Featured WorkshopFree
ReactJS is wildly popular and thus wildly supported. TypeScript is increasingly popular, and thus increasingly supported.

The two together? Not as much. Given that they both change quickly, it's hard to find accurate learning materials.

React+TypeScript, with JetBrains IDEs? That three-part combination is the topic of this series. We'll show a little about a lot. Meaning, the key steps to getting productive, in the IDE, for React projects using TypeScript. Along the way we'll show test-driven development and emphasize tips-and-tricks in the IDE.
React Advanced Conference 2021React Advanced Conference 2021
145 min
Web3 Workshop - Building Your First Dapp
Top Content
Featured WorkshopFree
In this workshop, you'll learn how to build your first full stack dapp on the Ethereum blockchain, reading and writing data to the network, and connecting a front end application to the contract you've deployed. By the end of the workshop, you'll understand how to set up a full stack development environment, run a local node, and interact with any smart contract using React, HardHat, and Ethers.js.
React Summit 2022React Summit 2022
136 min
Remix Fundamentals
Top Content
Featured WorkshopFree
Building modern web applications is riddled with complexity And that's only if you bother to deal with the problems
Tired of wiring up onSubmit to backend APIs and making sure your client-side cache stays up-to-date? Wouldn't it be cool to be able to use the global nature of CSS to your benefit, rather than find tools or conventions to avoid or work around it? And how would you like nested layouts with intelligent and performance optimized data management that just works™?
Remix solves some of these problems, and completely eliminates the rest. You don't even have to think about server cache management or global CSS namespace clashes. It's not that Remix has APIs to avoid these problems, they simply don't exist when you're using Remix. Oh, and you don't need that huge complex graphql client when you're using Remix. They've got you covered. Ready to build faster apps faster?
At the end of this workshop, you'll know how to:- Create Remix Routes- Style Remix applications- Load data in Remix loaders- Mutate data with forms and actions
Vue.js London Live 2021Vue.js London Live 2021
169 min
Vue3: Modern Frontend App Development
Top Content
Featured WorkshopFree
The Vue3 has been released in mid-2020. Besides many improvements and optimizations, the main feature of Vue3 brings is the Composition API – a new way to write and reuse reactive code. Let's learn more about how to use Composition API efficiently.

Besides core Vue3 features we'll explain examples of how to use popular libraries with Vue3.

Table of contents:
- Introduction to Vue3
- Composition API
- Core libraries
- Vue3 ecosystem

Prerequisites:
IDE of choice (Inellij or VSC) installed
Nodejs + NPM
JSNation 2023JSNation 2023
174 min
Developing Dynamic Blogs with SvelteKit & Storyblok: A Hands-on Workshop
Featured WorkshopFree
This SvelteKit workshop explores the integration of 3rd party services, such as Storyblok, in a SvelteKit project. Participants will learn how to create a SvelteKit project, leverage Svelte components, and connect to external APIs. The workshop covers important concepts including SSR, CSR, static site generation, and deploying the application using adapters. By the end of the workshop, attendees will have a solid understanding of building SvelteKit applications with API integrations and be prepared for deployment.
React Summit 2023React Summit 2023
106 min
Back to the Roots With Remix
Featured Workshop
The modern web would be different without rich client-side applications supported by powerful frameworks: React, Angular, Vue, Lit, and many others. These frameworks rely on client-side JavaScript, which is their core. However, there are other approaches to rendering. One of them (quite old, by the way) is server-side rendering entirely without JavaScript. Let's find out if this is a good idea and how Remix can help us with it?
Prerequisites- Good understanding of JavaScript or TypeScript- It would help to have experience with React, Redux, Node.js and writing FrontEnd and BackEnd applications- Preinstall Node.js, npm- We prefer to use VSCode, but also cloud IDEs such as codesandbox (other IDEs are also ok)