Desarrollo y Fomento de Bibliotecas de Componentes

This ad is not shown to multipass and full ticket holders
JSNation US
JSNation US 2025
November 17 - 20, 2025
New York, US & Online
See JS stars in the US biggest planetarium
Learn More
In partnership with Focus Reactive
Upcoming event
JSNation US 2025
JSNation US 2025
November 17 - 20, 2025. New York, US & Online
Learn more
Bookmark
Rate this content

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

This talk has been presented at React Advanced 2022, check out the latest edition of this React Conference.

FAQ

Lachlan considera que la API es el aspecto más importante de una buena biblioteca de componentes, enfatizando que debe balancearse entre ser rígida para facilitar su uso y garantizar consistencia, y ser lo suficientemente flexible para cubrir diversos casos de uso sin complicar demasiado su implementación.

El equipo comienza con una API muy rígida, centrada en resolver problemas difíciles como la accesibilidad y la animación, y se mueven hacia una mayor flexibilidad según sea necesario, siempre intentando cubrir el 90% de los casos de uso comunes y facilitando que los equipos manejen el 10% restante.

Logan utiliza métricas como la tasa de adopción y la cobertura de componentes, que indican cuánto los ingenieros desean y realmente usan los componentes de Tux, además de herramientas de análisis de código estático como TuxScanner para recoger datos sobre el uso práctico de la biblioteca.

TuxScanner es una herramienta de análisis de código estático que evalúa cómo se utiliza la biblioteca de componentes Tux, recopilando datos que ayudan a entender y mejorar la tasa de adopción y la eficacia de la biblioteca mediante el análisis de los archivos de código fuente.

En TikTok, los cambios disruptivos son manejados a través de la práctica de co-propiedad, donde el equipo de Tux tiene la responsabilidad de actualizar los consumidores de la biblioteca a la última versión, garantizando que todos los usuarios estén al día y maximizando la adopción de nuevas mejoras.

Logan Ralston
Logan Ralston
Lachlan Bradford
Lachlan Bradford
22 min
24 Oct, 2022

Comments

Sign in or register to post your comment.
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

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

No resuelvas problemas, elimínalos
React Advanced 2021React Advanced 2021
39 min
No resuelvas problemas, elimínalos
Top Content
Kent C. Dodds discusses the concept of problem elimination rather than just problem-solving. He introduces the idea of a problem tree and the importance of avoiding creating solutions prematurely. Kent uses examples like Tesla's electric engine and Remix framework to illustrate the benefits of problem elimination. He emphasizes the value of trade-offs and taking the easier path, as well as the need to constantly re-evaluate and change approaches to eliminate problems.
Sistemas de Diseño: Caminando la Línea Entre Flexibilidad y Consistencia
React Advanced 2021React Advanced 2021
47 min
Sistemas de Diseño: Caminando la Línea Entre Flexibilidad y Consistencia
Top Content
The Talk discusses the balance between flexibility and consistency in design systems. It explores the API design of the ActionList component and the customization options it offers. The use of component-based APIs and composability is emphasized for flexibility and customization. The Talk also touches on the ActionMenu component and the concept of building for people. The Q&A session covers topics such as component inclusion in design systems, API complexity, and the decision between creating a custom design system or using a component library.
Los Átomos de Jotai Son Simplemente Funciones
React Day Berlin 2022React Day Berlin 2022
22 min
Los Átomos de Jotai Son Simplemente Funciones
Top Content
State management in React is a highly discussed topic with many libraries and solutions. Jotai is a new library based on atoms, which represent pieces of state. Atoms in Jotai are used to define state without holding values and can be used for global, semi-global, or local states. Jotai atoms are reusable definitions that are independent from React and can be used without React in an experimental library called Jotajsx.
Depuración de JS
React Summit 2023React Summit 2023
24 min
Depuración de JS
Top Content
Debugging JavaScript is a crucial skill that is often overlooked in the industry. It is important to understand the problem, reproduce the issue, and identify the root cause. Having a variety of debugging tools and techniques, such as console methods and graphical debuggers, is beneficial. Replay is a time-traveling debugger for JavaScript that allows users to record and inspect bugs. It works with Redux, plain React, and even minified code with the help of source maps.
El Epic Stack
React Summit US 2023React Summit US 2023
21 min
El Epic Stack
Top Content
This Talk introduces the Epic Stack, a project starter and reference for modern web development. It emphasizes that the choice of tools is not as important as we think and that any tool can be fine. The Epic Stack aims to provide a limited set of services and common use cases, with a focus on adaptability and ease of swapping out tools. It incorporates technologies like Remix, React, Fly to I.O, Grafana, and Sentry. The Epic Web Dev offers free materials and workshops to gain a solid understanding of the Epic Stack.
Un Marco para Gestionar la Deuda Técnica
TechLead Conference 2023TechLead Conference 2023
35 min
Un Marco para Gestionar la Deuda Técnica
Top ContentPremium
Today's Talk discusses the importance of managing technical debt through refactoring practices, prioritization, and planning. Successful refactoring requires establishing guidelines, maintaining an inventory, and implementing a process. Celebrating success and ensuring resilience are key to building a strong refactoring culture. Visibility, support, and transparent communication are crucial for addressing technical debt effectively. The team's responsibilities, operating style, and availability should be transparent to product managers.

Workshops on related topic

React, TypeScript y TDD
React Advanced 2021React Advanced 2021
174 min
React, TypeScript y TDD
Top Content
Featured Workshop
Paul Everitt
Paul Everitt
ReactJS es extremadamente popular y, por lo tanto, ampliamente soportado. TypeScript está ganando popularidad y, por lo tanto, cada vez más soportado.

¿Los dos juntos? No tanto. Dado que ambos cambian rápidamente, es difícil encontrar materiales de aprendizaje precisos.

¿React+TypeScript, con los IDEs de JetBrains? Esa combinación de tres partes es el tema de esta serie. Mostraremos un poco sobre mucho. Es decir, los pasos clave para ser productivo, en el IDE, para proyectos de React utilizando TypeScript. En el camino, mostraremos el desarrollo guiado por pruebas y enfatizaremos consejos y trucos en el IDE.
Masterclass Web3 - Construyendo Tu Primer Dapp
React Advanced 2021React Advanced 2021
145 min
Masterclass Web3 - Construyendo Tu Primer Dapp
Top Content
Featured Workshop
Nader Dabit
Nader Dabit
En esta masterclass, aprenderás cómo construir tu primer dapp de pila completa en la blockchain de Ethereum, leyendo y escribiendo datos en la red, y conectando una aplicación de front end al contrato que has desplegado. Al final de la masterclass, entenderás cómo configurar un entorno de desarrollo de pila completa, ejecutar un nodo local e interactuar con cualquier contrato inteligente usando React, HardHat y Ethers.js.
Construye un Tablero Rico en Datos y Hermoso con la Rejilla de Datos de MUI X y Joy UI
React Summit 2023React Summit 2023
137 min
Construye un Tablero Rico en Datos y Hermoso con la Rejilla de Datos de MUI X y Joy UI
Top Content
WorkshopFree
Sam Sycamore
Siriwat (Jun) Kunaporn
2 authors
Aprende cómo utilizar el ecosistema completo de MUI para construir un tablero de gestión de proyectos hermoso y sofisticado en una fracción del tiempo que tomaría construirlo desde cero. En particular, veremos cómo integrar la Rejilla de Datos de MUI X con Joy UI, nuestra biblioteca de componentes más nueva y hermana del estándar de la industria Material UI.
Tabla de contenidos:- Presentando nuestro proyecto y herramientas- Configuración de la aplicación e instalación del paquete- Construcción del tablero- Prototipado, estilos y temas - Características de Joy UI- Filtrado, ordenación, edición - Características de la Rejilla de Datos- Conclusión, pensamientos finales, P&R
Fundamentos de Remix
React Summit 2022React Summit 2022
136 min
Fundamentos de Remix
Top Content
Workshop
Kent C. Dodds
Kent C. Dodds
Construir aplicaciones web modernas está lleno de complejidad. Y eso solo si te molestas en lidiar con los problemas
¿Cansado de conectar onSubmit a las API del backend y asegurarte de que tu caché del lado del cliente se mantenga actualizada? ¿No sería genial poder utilizar la naturaleza global de CSS en tu beneficio, en lugar de buscar herramientas o convenciones para evitarla o trabajar alrededor de ella? ¿Y qué te parecería tener diseños anidados con una gestión de datos inteligente y optimizada para el rendimiento que simplemente funciona™?
Remix resuelve algunos de estos problemas y elimina completamente el resto. Ni siquiera tienes que pensar en la gestión de la caché del servidor o en los conflictos del espacio de nombres global de CSS. No es que Remix tenga APIs para evitar estos problemas, simplemente no existen cuando estás usando Remix. Ah, y no necesitas ese enorme y complejo cliente graphql cuando estás usando Remix. Ellos te tienen cubierto. ¿Listo para construir aplicaciones más rápidas de manera más rápida?
Al final de esta masterclass, sabrás cómo:- Crear Rutas de Remix- Estilizar aplicaciones de Remix- Cargar datos en los cargadores de Remix- Mutar datos con formularios y acciones
Vue3: Desarrollo Moderno de Aplicaciones Frontend
Vue.js London Live 2021Vue.js London Live 2021
169 min
Vue3: Desarrollo Moderno de Aplicaciones Frontend
Top Content
Workshop
Mikhail Kuznetsov
Mikhail Kuznetsov
Vue3 fue lanzado a mediados de 2020. Además de muchas mejoras y optimizaciones, la principal característica que trae Vue3 es la API de Composición, una nueva forma de escribir y reutilizar código reactivo. Aprendamos más sobre cómo usar la API de Composición de manera eficiente.

Además de las características principales de Vue3, explicaremos ejemplos de cómo usar bibliotecas populares con Vue3.

Tabla de contenidos:
- Introducción a Vue3
- API de Composición
- Bibliotecas principales
- Ecosistema Vue3

Requisitos previos:
IDE de elección (Inellij o VSC) instalado
Nodejs + NPM
Desarrollando Blogs Dinámicos con SvelteKit & Storyblok: Una Masterclass Práctica
JSNation 2023JSNation 2023
174 min
Desarrollando Blogs Dinámicos con SvelteKit & Storyblok: Una Masterclass Práctica
Top Content
WorkshopFree
Alba Silvente Fuentes
Roberto Butti
2 authors
Esta masterclass de SvelteKit explora la integración de servicios de terceros, como Storyblok, en un proyecto SvelteKit. Los participantes aprenderán cómo crear un proyecto SvelteKit, aprovechar los componentes de Svelte y conectarse a APIs externas. La masterclass cubre conceptos importantes incluyendo SSR, CSR, generación de sitios estáticos y despliegue de la aplicación usando adaptadores. Al final de la masterclass, los asistentes tendrán una sólida comprensión de la construcción de aplicaciones SvelteKit con integraciones de API y estarán preparados para el despliegue.