Las Dilemas que Enfrenté al Construir una Biblioteca 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

¿Alguna vez has querido construir una biblioteca de componentes pero te sentiste demasiado intimidado? ¡No te preocupes! Te guiaré a través de los dilemas que enfrentarás al crear tu primera biblioteca de componentes. Te mostraré cómo considerar las soluciones correctas y compartiré algunas de mis experiencias personales. Al final, estarás equipado para compartir tu primera biblioteca con el mundo.

This talk has been presented at JSNation US 2024, check out the latest edition of this JavaScript Conference.

Andrico Karoulla
Andrico Karoulla
27 min
21 Nov, 2024

Comments

Sign in or register to post your comment.
Video Summary and Transcription
Construir una biblioteca de componentes implica tomar varias decisiones, como usar un framework de JavaScript, considerar la accesibilidad en las pruebas y usar un monorepo. Construir una biblioteca de componentes permite una creación de interfaces más rápida y un lenguaje visual consistente. Tomar la decisión equivocada puede llevar a asumir la complejidad de las interacciones. Delegar la complejidad a una biblioteca de código abierto puede ser beneficioso. Exportar como un solo paquete o paquetes con alcance tiene sus ventajas y desventajas. Establecer un flujo de trabajo específico y una estructura de repositorio es importante para publicar componentes. Se recomienda publicar como ESM y evitar empaquetar la biblioteca. Aprovechar las capacidades del navegador y usar herramientas fundamentales como CSS y TypeScript puede ser beneficioso.

1. The Dilemmas When Building Component Libraries

Short description:

Soy Indrico, y esta es mi charla, Los dilemas que enfrenté al construir mis bibliotecas de componentes. Construir una biblioteca de componentes es una parte realmente gratificante de ser un desarrollador web, pero no puedes simplemente juntar cualquier código antiguo y esperar que resuelva los problemas de todos. Así que esta charla es una culminación de todas esas pequeñas decisiones que he tenido que tomar al construir mis bibliotecas de componentes.

♪♪♪ Soy Indrico, y esta es mi charla, Los dilemas que enfrenté al construir mis bibliotecas de componentes, o también conocido como El sándwich perfecto no existe A menos que estés comiendo un sándwich hecho por JakeTheDog. Entonces, tienes hambre y quieres hacer un bocadillo. Así que tal vez quieras hacer un sándwich. Entonces comienzas tomando un poco de pan blanco Hovis, o tal vez sea Wonder Bread para aquellos en América. Para esto, vas a Sainsbury's y obtienes un poco de mayonesa de huevo prehecha. Luego cortas algunas deliciosas cebollas blancas crudas, las pones encima del sándwich y luego le echas montones de ketchup. Y felicidades, tienes un delicioso manjar.

Ahora, si has jugado Legend of Zelda, Tears of the Kingdom, y arrojaste esos ingredientes en una sartén, probablemente verías aparecer esta pequeña pantalla. Es comida dudosa. Es demasiado asqueroso para siquiera mirarlo. Un olor extraño emana de este montón. Comerlo no te hará daño, probablemente.

Entonces, digamos que trabajas para un restaurante de alta gama, y quieres hacer un sándwich elegante. Bueno, no puedes simplemente servir a tus clientes el sándwich que acabamos de hacer. Tienes que hacer algo un poco más agradable. En lugar de solo tu pan blanco simple, tal vez vayas a un montón de diferentes panaderías, pruebes sus panes, tal vez vayas por la sensación en la boca y la textura, y decidas sobre el perfecto pan de masa madre. No puedes simplemente echar cualquier ketchup viejo en ese pan de masa madre. En su lugar, haces tu famoso relish casero especial. Nuevamente, cebollas blancas crudas, sí, toman un segundo para cortar, pero si realmente quieres tomarte el tiempo y hacer algo delicioso, vas a caramelizarlas. Eso lleva mucho más tiempo, pero tus usuarios, lo siento, quiero decir tus clientes, apreciarán el tiempo y esfuerzo que pones en hacer esas cebollas caramelizadas.

Pero eso no es lo único que necesitas considerar cuando estás haciendo tu sándwich gourmet. Tienes que considerar cosas como el costo monetario para hacer el sándwich, los requisitos dietéticos de tus clientes, tal vez quieras atender a celíacos, o tal vez a personas sin lácteos, pero eso es algo que necesitas decidir lo mejor para ti. Pero luego también necesitas las habilidades y el equipo para hacer ese maldito sándwich. Y un hombre sabio una vez dijo, algo rápido y sucio podría funcionar para ti ahora, pero no será adecuado en cada situación. Y lo mismo ocurre al construir una biblioteca de componentes. Encuentro que construir una biblioteca de componentes es una parte realmente gratificante de ser un desarrollador web, pero no puedes simplemente juntar cualquier código antiguo y esperar que resuelva los problemas de todos. Hay mucho más que eso. Así que esta charla es una culminación de todas esas pequeñas decisiones que he tenido que tomar al construir mis bibliotecas de componentes. Así que aquí estamos, los dilemas que enfrentarás al construir una biblioteca de componentes. Así que me di cuenta de que al construir un componente para un equipo, o una empresa, o para la comunidad de código abierto, enfrentarás un montón de dilemas.

2. Big Choices in Component Library Building

Short description:

Estas son grandes decisiones al construir una biblioteca de componentes, como si usar un framework de JavaScript, considerar la accesibilidad en las pruebas y usar un monorepo. Tomar la decisión equivocada desde el principio puede tener consecuencias duraderas.

Ahora, estas son pequeñas decisiones como, bueno, tal vez no pequeñas, en realidad decisiones bastante grandes, si usar un framework de JavaScript, puede que no lo necesites, cómo considerar la accesibilidad dentro de tu estrategia de pruebas, que es algo que ciertamente querrás hacer, y si usar un monorepo para gestionar tu biblioteca de tres componentes, y spoilers, no lo hagas. Y tomar la decisión equivocada desde el principio puede causar dolores de cabeza duraderos para ti, tus compañeros de equipo y tus usuarios finales. Así que es importante considerar estas cosas. Y algunas de estas decisiones que se toman pueden ser cosas que puedes cambiar un poco más adelante. Tal vez te des cuenta después de investigar un poco que una alternativa es mejor que otras son más como puertas de un solo sentido, donde si cometes un error o eliges la opción incorrecta desde el principio, puede tener consecuencias duraderas mucho más adelante.

3. Benefits of Building Component Libraries

Short description:

Soy Andriuko Kirula, un desarrollador full-stack especializado en desarrollo front-end. He construido bibliotecas de componentes para empresas como Anima, Trin y Health Hero, así como algunas por diversión, incluyendo A2K y BeautifulSkillTree. Construir una biblioteca de componentes permite una creación de interfaces más rápida y un lenguaje visual consistente. También ayuda a mejorar la comprensión de diferentes ecosistemas, aprender componentes web y dominar patrones comunes de UI.

Para esto, antes de continuar, permíteme presentarme. Soy Andriuko Kirula, y soy un desarrollador full-stack, y he estado en el juego por casi una década ahora. Y me especializo en el front-end, y he construido algunas bibliotecas de componentes, principalmente para empresas, pero también algunas por diversión.

Actualmente estoy en busca de mi próximo rol de contrato. Así que si necesitas un desarrollador front-end o un desarrollador full-stack, entonces podría ser tu persona. Así que déjame hablar sobre algunas de las bibliotecas de componentes que he construido para empresas.

En mi último rol en Anima, teníamos un montón de diferentes front-ends que estaban construidos en React. Y por eso tenía sentido que creáramos una biblioteca de componentes en React que luego usamos en esos diferentes front-ends. Eso significaba que todos nuestros front-ends se veían y sentían de la misma manera. Y lo mismo ocurre con las bibliotecas de componentes que se construyen en Trin o a las que contribuí en Health Hero.

Y en cuanto a las que son por diversión, tomo un enfoque ligeramente diferente. Muchas veces lo hago para satisfacer una inquietud creativa o para aprender una tecnología a un nivel más profundo. Y puedes ver mi favorita que hice es A2K, que es una biblioteca de componentes inspirada en Windows 2000. Y puedes ver aquí que los diferentes componentes que exporta le dan a tus interfaces este genial toque retro. Y he construido un par de bibliotecas de componentes independientes. Y también he construido una biblioteca de componentes React llamada BeautifulSkillTree. No la he actualizado en un tiempo, pero parece tener un poco de seguimiento de culto.

Genial. Entonces, ¿por qué construyo bibliotecas de componentes? ¿O por qué deberías construir bibliotecas de componentes? La respuesta empresarial es que construir una biblioteca de componentes te permite construir tus interfaces más rápido usando componentes reutilizables. Y luego eso te permite tener un lenguaje visual consistente a través de tus diferentes interfaces. Pero luego, a un nivel más personal, prefiero escribir... Bueno, me gusta escribir bibliotecas de componentes porque te permite entender mejor un ecosistema dado. Si quieres mejorar escribiendo en React o Svelte, entonces una muy buena manera de hacerlo es escribiendo algunos componentes complejos en ese framework.

Lo mismo ocurre si quieres aprender componentes web. Una gran manera de hacerlo es construyendo componentes. También te ayuda a mejorar tu comprensión de patrones comunes de UI. Si has intentado construir un menú select o has intentado construir un acordeón desde cero, probablemente pronto te darás cuenta de que no es tan simple como podría parecer. Tienes muchos subcomponentes que podrías necesitar construir, muchas interacciones complicadas y casos especiales que también necesitas acomodar. Y a un nivel meta, si quieres mejorar en desarrollar y publicar una biblioteca, la mejor manera de hacerlo es desarrollando y publicando una biblioteca. Así que genial, hemos hablado sobre los beneficios de construir una biblioteca de componentes.

4. Making Decisions in Component Library Development

Short description:

Construir una biblioteca de componentes implica tomar varias decisiones. Una pregunta es si escribir componentes desde cero o usar una biblioteca. Considera los frameworks utilizados por los frontends que utilizarán la biblioteca de componentes. Si se involucran múltiples frameworks, los Web Components pueden ser una opción adecuada. Elegir Web Components lleva a más preguntas, como usar Vanilla Web Components, una biblioteca auxiliar como Lit o Atomico, o una biblioteca existente como SheLace o WebAwesome. De manera similar, si se construye con un framework, las opciones incluyen Vanilla React, Radix, React ARIA, Mui o Shadtian. Estas preguntas giran en torno al nivel de abstracción y la complejidad deseada. Tomar la decisión equivocada puede llevar a asumir la complejidad de las interacciones.

Pero no es tan sencillo porque, como mencioné antes, hay un montón de decisiones diferentes que necesitas tomar si quieres hacer una biblioteca de componentes que sea adecuada para tus usuarios.

Para esto, y estas son solo algunas de las preguntas con las que me he encontrado al construir mis propias bibliotecas de componentes. Y de hecho, saqué esta lista de un artículo de GitHub que escribí, que detalla todas mis experiencias a través de estas diferentes preguntas. Así que si eso suena como algo que te interesa, entonces genial, porque esta charla tomará un puñado de estas preguntas y profundizará en ellas. Pero si quieres revisar ese artículo de GitHub y contribuir con tus propias experiencias, entonces eso es genial. Así que por favor, adelante y hazlo.

Así que la primera que veremos es si deberías escribir tus componentes desde cero o construir los tuyos propios. Así que la primera pregunta es si quieres construir tu componente, usando una biblioteca. Y una buena manera de entender si eso es una buena idea o no es mirar todos los diferentes frontends con los que planeas usar tu biblioteca de componentes. Si todos usan el mismo framework, entonces tal vez sea una buena idea escribir tu biblioteca de componentes en ese framework. Si tienes un frontend de Vue, un frontend de Svelte y un frontend de React, entonces tal vez considera usar Web Components, porque puedes usarlos en muchos frameworks diferentes. Así que ya hemos llegado a una bifurcación en el camino aquí. Tenemos como si usar Web Components para una biblioteca de componentes, si usar un framework específico, y también hay otras opciones. Y esto es algo que verás mucho cuando construyas la tuya propia, es que responder una pregunta a menudo lleva a muchas otras preguntas.

Así que tomemos como la bifurcación izquierda, donde usas Web Components. Bien, genial, pero ahora hay toda una serie de preguntas que necesitas responder. ¿Quieres escribir Vanilla Web Components, que es una API de nivel más bajo, un poco más compleja, pero obtienes control total sobre cómo se comportan? ¿O quieres usar una biblioteca auxiliar como Lit o Atomico que suavizan algunos de los bordes más complicados y te dan cosas como reactividad de inmediato? ¿O quieres usar una biblioteca existente como SheLace o WebAwesome, o en realidad lo mismo, pero donde te ofrecen una suite de componentes completamente funcionales que puedes instalar para satisfacer tus necesidades? Y luego encuentras que si elegiste construir en un framework, tienes un conjunto similar de preguntas también, si escribir tus componentes en Vanilla React, si quieres usar una biblioteca como Radix o React ARIA que te dan componentes sin estilo, pero manejan muchas de las interacciones más complejas para patrones de UI complejos. O tal vez usar una biblioteca como Mui o Shadtian, donde obtienes componentes completamente funcionales, y luego tienes la opción de personalizarlos.

Y así, estos son más detalles de implementación. Pero si damos un paso atrás, notarás algunos paralelismos entre esas dos preguntas, a saber, con qué nivel de abstracción te sientes cómodo tratando. Así que diferentes niveles de abstracción tratan con... Diferentes niveles de abstracción ofrecen soluciones a diferentes problemas. Como soluciones a diferentes problemas. Así que yendo desde el nivel más alto de abstracción, podrías usar una biblioteca de componentes con componentes funcionales que ya se ven geniales. Y así, para ti como desarrollador, tienes que lidiar con mucha menos complejidad, y luego también puedes construir algo o entregar algo mucho más rápidamente. Y luego nuevamente, si usas componentes funcionales que no tienen estilo, no tienes que lidiar demasiado con el funcionamiento interno de los componentes y cómo se comportan. Solo necesitas asegurarte de que se vean exactamente como los necesitas. Luego das otro paso, como bajar un nivel, y tal vez estás usando una biblioteca para ayudarte a escribir componentes, pero aún necesitas implementar toda la funcionalidad del componente tú mismo, o escribes componentes desde cero sin una biblioteca. Y nuevamente, eso es lo más complejo de todos porque estás lidiando con cosas como el estilo y la interactividad, y tal vez las APIs de nivel más bajo que ofrece el navegador. Así que he tomado la decisión equivocada en varias ocasiones, y probablemente voy a tomar la decisión equivocada en el futuro también.

5. Considerations in Component Library Development

Short description:

Construir componentes desde cero puede llevar a asumir la complejidad de las interacciones. Se vuelve desafiante cuando se trabaja en equipo, ya que diferentes individuos pueden introducir cambios que se desvían de la visión original. Delegar la complejidad a una biblioteca de código abierto puede ser beneficioso, ya que tiene un equipo dedicado a construir bibliotecas de componentes. Sin embargo, hay razones para elegir diferentes niveles de abstracción, como aprender un framework o considerar las contribuciones de otros.

Ha habido ocasiones en las que he hecho componentes desde cero, y el desafío con eso es que ahora soy dueño de la complejidad de las interacciones. Y así se hace más difícil si estás trabajando en un equipo y estás construyendo todo desde cero porque ahora tienes muchas personas diferentes entrando y ajustando cosas, y tal vez la visión original se ha enturbiado, así que ahora tienes este componente Hero donde tienes un botón, un botón de enlace y un enlace todo en el mismo componente haciendo muchas cosas diferentes. Y así ahora tengo estas implementaciones complejas con preocupaciones mezcladas, y habrá montones de casos límite. Y así a veces podría tener más sentido delegar toda esa complejidad a una biblioteca de código abierto, y tal vez esa biblioteca tenga un equipo que esté dedicado a resolver un solo problema, y ese único problema es construir una biblioteca de componentes. Y esa biblioteca de componentes puede haber sido utilizada en decenas de miles de proyectos diferentes, así que ahora tienes todas las estadísticas de uso para informar cómo se comporta esa biblioteca de componentes. Y así no tienes esa carga de mantenimiento que podrías tener si construyeras todo tú mismo. Pero no es necesariamente lo mejor delegar siempre la complejidad a otra persona. Hay diferentes razones para elegir esos niveles de abstracción. Así que tal vez quieras aprender un framework a un nivel más profundo. Bueno, entonces tal vez sea bueno intentar construir todo desde cero. También necesitas considerar quién va a contribuir a tu biblioteca de componentes. Si eres solo tú, entonces adelante, y tal vez las cosas sean un poco más desordenadas, no te importa eso un poco, pero si estás trabajando con un equipo o esperas contribuciones de código abierto, entonces necesitas ser un poco más metódico sobre cómo escribes las cosas y si hacer que sea lo más fácil posible para que otros contribuyan.

6. Exporting Single vs Scoped Packages

Short description:

La siguiente pregunta que vamos a analizar es si exportar tu biblioteca como un paquete único o como paquetes con ámbito. Exportar como un paquete único da acceso a toda la suite de componentes, facilitando las actualizaciones y la gestión. Por otro lado, los paquetes con ámbito permiten instalar y usar componentes específicos, reduciendo el tamaño del paquete. Los autores de componentes tienen flexibilidad en la versionado y publicación, ya sea de forma independiente o conjunta. Sin embargo, versionar conjuntamente puede llevar a dificultades de actualización cuando se usa un gran número de componentes. Publicar paquetes con ámbito puede aumentar la fricción y disminuir la adopción, especialmente cuando los usuarios planean usar todos los componentes de la biblioteca. Gestionar versiones independientes requiere un flujo de trabajo específico y un incremento cuidadoso de versiones.

Genial, así que esa es la primera pregunta que cubrimos, y prácticamente llevó a otra docena de preguntas, pero espero que tengas una mejor comprensión sobre el tipo de introspección que necesitas hacer si quieres comenzar a construir tu primera biblioteca de componentes.

Así que la siguiente pregunta que vamos a analizar es si exportar tu biblioteca como un paquete único o como paquetes con ámbito. ¿Y a qué me refiero con esto?

Bueno, si has usado bibliotecas de componentes en el pasado, tal vez Material Web, sabrás que si ejecutas npm install Material Web o cualquier biblioteca de componentes, tendrás acceso a toda la suite de componentes, y esto es realmente útil como consumidor porque si estás consumiendo este tipo de biblioteca de componentes, entonces solo necesitas ejecutar el script de actualización contra un paquete para obtener la última versión de todos los componentes. Puedes mirar fácilmente los registros de cambios.

Y si estás gestionando la biblioteca de componentes tú mismo, es mucho más fácil gestionar una sola versión y luego publicar una sola versión. Para esto, y lo contrastaré con los paquetes con ámbito, y esto podría, bueno, esto es como un Radix UI donde podrías querer usar, digamos, su menú select y tal vez sus componentes de menú popover, y entonces necesitarías ejecutar npm install Radix UI, select menu, y luego npm install Radix UI popover. Así que instalar un solo paquete te da acceso a un solo componente. Y esto es útil si solo planeas usar, digamos, uno o dos, o un número muy, muy pequeño de componentes de una biblioteca dada.

Y tengo un asterisco aquí sobre la reducción de tamaños de paquete, lo cual tal vez no sea estrictamente cierto, lo cual toco un poco más adelante, pero como autor de componentes o autor de biblioteca, tienes mucha flexibilidad en cuanto a cómo los versionas y publicas. Puedes publicarlos, versionarlos independientemente para que cada componente tenga su propia versión, o puedes versionarlos juntos para que cada vez que lances, aumentes la versión para todos ellos y tal vez solo algunos de los cambios, solo se realicen cambios en algunos de esos componentes. Y hablaremos un poco sobre esa última opción en un segundo, porque encuentro eso realmente molesto como consumidor. He trabajado con paquetes independientes que fueron versionados juntos.

Y aunque el sistema de plugins de Gatsby no era necesariamente como una biblioteca de componentes, lo que harías, si has construido con Gatsby en el pasado, probablemente usarías una docena o más de estos diferentes plugins de primera parte, y todos estaban versionados juntos contra la misma versión. Y así lo que sucedería es que si te alejabas de tu computadora por un par de semanas, volvías e intentabas actualizar tus dependencias, verías una lista completa de plugins de Gatsby que necesitaban ser actualizados, y así cuando revisas cada registro de cambios, porque no me gusta simplemente actualizar todo y esperar lo mejor, a menudo verías esto, como aumento de versión, aumento de versión, aumento de versión, aumento de versión, oh, pequeño cambio en el readme, aumento de versión, aumento de versión. Y tendrías que hacer eso a través de una docena o más, si no más, paquetes. Así que eso es un poco molesto. Pero no es tan malo si estás usando un pequeño número de componentes y están versionados independientemente.

De esa manera, tal vez te hayas alejado de tu computadora por dos semanas y solo uno de esos componentes ha cambiado. Así que no necesitas actualizar todos ellos. Ahora, como editor, de hecho he lidiado con la publicación de paquetes con ámbito. Y hablé sobre mi biblioteca de componentes A2K un poco antes. Y para ser totalmente honesto, fue un error y lo lamento enormemente. Así que el propósito de A2K era permitir a las personas construir una interfaz completa usando una suite de componentes de estilo retro. Entonces, ¿por qué haría que mis desarrolladores o mis consumidores instalen cada componente individualmente? Simplemente no tiene sentido. Si planean usar A2K para construir una interfaz, probablemente usarán todos los componentes. Así que hacer que alguien instale 12 componentes mata absolutamente la experiencia de usuario y aumenta la fricción. Y probablemente diría que la adopción habría sido un poco más alta si hubiera publicado todo como un solo componente. Además de eso, gestionar versiones independientes es un poco más complejo.

7. Setting Up Repo for Publishing Components

Short description:

Para publicar componentes a medida que cambian y gestionar versiones, configura tu repositorio con un flujo de trabajo específico. Simplifica el proceso y evita herramientas innecesarias. Cambiar la estructura de una biblioteca de componentes muy utilizada puede ser un desafío, así que elige el mejor enfoque desde el principio.

Así que necesitas configurar tu repositorio como un repositorio modelo. Necesitan tener un flujo de trabajo específico para que puedas publicar componentes a medida que cambian y asegurarte de que las versiones se incrementen según el cambio. Y me gusta, uso change sets para esto. Y me gusta como herramienta, pero hace que, o tener todas estas herramientas en tu repositorio simplemente lo hace mucho más difícil de manejar. Así que intenta optar por la opción más simple si puedes. Y hablé sobre problemas de puerta de un solo sentido anteriormente. Y creo que este es un buen ejemplo. Si quisiera cambiar A2K ahora para ser una sola biblioteca o un solo paquete con todos los componentes, tendría que pedirle a todos los que lo usan que cambien completamente la forma en que están usando la biblioteca de componentes. Y no muchas personas lo usan ahora, pero si estás construyendo una biblioteca de componentes que es utilizada por miles de diferentes desarrolladores, les estás pidiendo mucho. Así que es mejor asegurarse de que has resuelto este problema o al menos tomar lo que sientes que es el mejor enfoque en ese momento. Así que definitivamente vale la pena considerarlo.

8. Creating Component Library with Single Package

Short description:

Para crear una biblioteca de componentes, ofrece un solo paquete escrito en ESM. Publicar como ESM es adecuado para componentes web, y los empaquetadores pueden eliminar los componentes no utilizados. Considera un solo paquete si tienes un lenguaje de diseño consistente y esperas que los usuarios utilicen múltiples componentes, de lo contrario, publícalos de manera independiente.

Entonces, ¿qué haría ahora? Para empezar, ofrecería un solo paquete por las razones que mencioné, también escribiría el paquete solo en ESM. Una cosa que no mencioné, porque es parte de un dilema diferente es que publiqué A2K como ESM, CommonJS y UMD. Y esto es, nuevamente, porque quería hacerlo lo más disponible posible para que cualquiera pudiera usarlo. Pero, en retrospectiva, es un componente web. Probablemente se usarán en la web. ESM es amigable con la web. Así que tiene sentido que solo publique como ESM a menos que realmente, realmente necesite usar CommonJS por cualquier razón. Para esto, además, porque ESM, como los módulos ES son analizables estáticamente, si un consumidor solo quiere usar un solo componente, entonces su empaquetador debería poder eliminar cualquiera de los componentes no utilizados. Así que no necesitas preocuparte demasiado por los tamaños de los paquetes. Y de lo que hablé un poco, por qué usaría un solo paquete, porque A2K tiene un lenguaje de diseño consistente. Así que no tenía sentido que estuviera todo separado. Así que cada vez que empiezo una nueva biblioteca de componentes, me hago estas cuatro preguntas. Y ya he tocado algunas de ellas hasta cierto punto. Pero si dices que sí a todas ellas, nuevamente, lenguaje de diseño con opinión, evitando la complejidad, esperando que los usuarios utilicen múltiples componentes y feliz de versionar todo junto, entonces probablemente sea mejor simplemente poner todo en un solo paquete. Pero si dices que no a una o más de estas, entonces podría ser mejor intentar y publicarlos de manera independiente.

9. Tooling for Building and Bundling

Short description:

¿Debería empaquetar mi biblioteca? No, porque es muy molesto. Las optimizaciones de una biblioteca empaquetada pueden no alinearse con las necesidades de los usuarios finales. Depurar se vuelve difícil cuando el código está empaquetado. Publica código amigable para el navegador y permite a los usuarios ejecutar una configuración de compilación si es necesario. Usa diferentes herramientas como TypeScript y SAS para mejorar la experiencia de desarrollo.

Genial. Así que este es el último elemento que vamos a revisar en esta charla. ¿Debería usar herramientas para construir y/o empaquetar mi biblioteca de componentes? Así que estamos en dos lados de esto. Está la construcción y está el empaquetado. Y cuando digo empaquetar, me refiero a ejecutar cosas como, ya sabes, combinando todo en un solo paquete en el que tal vez estés concatenando, minificando, transpiliendo. Mientras que construir es simplemente convertir algo, como ejecutar algunos pasos para hacer tu código amigable para el navegador código amigable para el navegador.

Así que veamos primero el empaquetado. ¿Debería empaquetar mi biblioteca? Y voy a decir que no porque es muy molesto. He estado en el extremo receptor de lidiar con una biblioteca empaquetada. Y la razón por la que fue un dolor para mí es porque las optimizaciones que esa biblioteca hizo no estaban en línea con lo que necesitaba para dar a mis usuarios finales. Así que esta biblioteca que he usado en el pasado, y realmente me gustó. Y pienso muy bien del equipo por esto. Ellos, bueno, la usamos bastante. Encontramos algunos errores aquí y allá, lo cual es de esperar. Pero lo que haríamos es depurar los módulos de nodo y luego tal vez ejecutar un paquete de parches si necesitábamos hacer algunos pequeños cambios mientras esperábamos que nuestras correcciones de errores de solicitud de extracción se integraran. Y todo eso estaba bien porque el código era básicamente solo módulos ES estándar como los desarrolladores lo habían escrito. Pero luego lo actualizamos un día y decidieron empaquetar su código. Así que en lugar de ser como muchos y muchos archivos diferentes, había solo como este archivo común JS que tenía todo el código empaquetado. Y fue un absoluto dolor depurarlo. Y les pedí que no hicieran eso, que revirtieran sus cambios. Y después de unas semanas lo hicieron. Y fue una experiencia de desarrollo mucho más agradable como consumidor.

Así que solo para reiterar, no asumas las necesidades de optimización de tus consumidores. Solo publica como códigos amigables para el navegador que si quieren ejecutar como una configuración de lista de compilación, entonces no necesitarán hacer ningún cambio a tu código. Los pasos de construcción son un poco diferentes. Para esto... Podrías querer usar diferentes herramientas para hacer tu experiencia de desarrollo un poco mejor como autor de la biblioteca. Podrías usar TypeScript porque te gusta el análisis estático que te da. Podrías querer agregar tipos a tu código también. SAS te da cosas como tal vez funciones que no están disponibles en CSS.

10. Challenges with Browser-Unfriendly Technologies

Short description:

El código que no es compatible con el navegador no funcionará en el navegador. Agregar un compilador a tu repositorio es necesario para usar TypeScript. Puede surgir fricción entre escribir código y verlo funcionar. Usar herramientas complejas como compiladores puede introducir puntos únicos de fallo. Algunos desarrolladores han cambiado a herramientas más simples para facilitar el desarrollo de componentes.

Y Stencil te permite escribir componentes en su sintaxis dada, que luego se compila a componentes web de vanilla. Pero el desafío con estos es que no son tecnologías amigables para el navegador. Y voy a decir algo bastante impactante aquí, y es que el código que no es compatible con el navegador no funcionará en el navegador. Y lo que eso significa es que si quieres usar TypeScript, tendrás que agregar un compilador a tu repositorio para asegurar que el código que escribes realmente se convierta en código amigable para el navegador. Y así, si estás escribiendo un componente en TypeScript, antes de que ese código se renderice en el navegador, necesita pasar por ese paso de compilación. Y así, hay este nivel de fricción entre escribir el código y realmente verlo funcionar. Y eso puede estar bien para ti. Tal vez esa compensación no sea un problema. Si estás trabajando solo y realmente te gusta TypeScript, esa podría ser una buena opción. Pero si estás trabajando en un equipo o estás trabajando en un proyecto de código abierto, entonces podrías darte cuenta de que cualquiera que quiera contribuir tiene que entender cómo funciona todo. Y eso podría simplemente hacer las cosas un poco más complejas. Lo mismo ocurre con tener un compilador, incluso si es TypeScript, Stencil, lo que sea, es que ahora hay esta caja negra, que podría ser un punto único de fallo. Y así podrías terminar luchando con esta herramienta si no está funcionando de la manera que esperas. Y recuerdo haber leído un artículo de los desarrolladores de Shoelace. Y él dijo que usó Stencil inicialmente para construir los componentes web de Shoelace. Pero luego de un tiempo, simplemente seguía chocando contra el compilador y terminó cambiándose a Lit porque era una herramienta mucho más simple que le permitía escribir sus componentes web. Y otro ejemplo es el equipo de Svelte. Inicialmente escribieron la biblioteca en TypeScript, pero optaron por eliminar TypeScript, volver a JavaScript vanilla, y escribir sus tipos en JSDoc. Y esto fue útil porque hizo mucho más fácil que la gente contribuyera.

11. Leveraging Browser Capabilities and Dilemmas

Short description:

No necesitas evitar todas las herramientas útiles. TypeScript se puede usar para generar tipos desde JSDoc antes de publicar. Mantén las cosas simples y aprovecha las capacidades del navegador. Familiarizarse con herramientas fundamentales como CSS y TypeScript puede ser beneficioso. Consulta el artículo de GitHub para más dilemas y siéntete libre de contribuir.

Y ahora, lo que podrías querer ser, podrías querer considerar es no sobrecorregir. Es fácil pasar de tener montones y montones de diferentes, herramientas de construcción allí para luego eliminar todo y solo asegurarte de que escribes tu código como un navegador lo leerá y evitar cualquier otra cosa como pruebas y tipos o lo que sea. Pero lo bueno es que no necesitas evitar todas esas cosas geniales. En lugar de escribir TypeScript y ejecutar el empaquetador antes de ejecutar tu código en el navegador, puedes en lugar de escribir tus tipos JSDoc y tener un paso de TypeScript literalmente justo antes de publicar para generar tipos desde tu JSDoc, y de esa manera puedes publicar tus tipos para que tus consumidores los usen. Así que no necesitas eliminar completamente todo o prescindir de todas estas herramientas útiles. Puedes simplemente hacer que sea lo más fácil posible para que otros contribuyan.

Así que mi enfoque, probablemente adivinaste que me gusta mantener las cosas bastante simples ahora. He pasado de un extremo de hacer las cosas lo más complejas posible, y ahora estoy como balanceándome en la otra dirección. Me gusta apoyarme en las capacidades del navegador, pero no estoy completamente en el campo de como nada más en absoluto. Un buen ejemplo es que te familiarizas mucho más con las herramientas en el navegador. Como creo que CSS es genial, y es súper capaz, particularmente en los últimos años. Así que ni siquiera he necesitado usar SAS o módulos CSS. Y tal vez en el pasado, solía simplemente usar SAS porque era a lo que estaba acostumbrado. Pero apoyarse, familiarizarse más con las herramientas fundamentales podría abrirte los ojos a que son mejores de lo que tal vez les das crédito. Lo mismo ocurre con TypeScript. Me gusta usarlo en mis aplicaciones, pero prefiero usar JS Dock al escribir mis bibliotecas.

Genial. Así que he cubierto unos tres dilemas diferentes, pero en el artículo de GitHub que mencioné antes, cubro mucho más. Así que si te gustaría aprender un poco más, entonces por favor échale un vistazo y tal vez incluso contribuye con tus propias historias. Eso es todo de mi parte, y agradezco que hayas visto, y que tengas un buen día. Adiós.

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

Construyendo Mejores Sitios Web con Remix
React Summit Remote Edition 2021React Summit Remote Edition 2021
33 min
Construyendo Mejores Sitios Web con Remix
Top Content
Remix is a web framework built on React Router that focuses on web fundamentals, accessibility, performance, and flexibility. It delivers real HTML and SEO benefits, and allows for automatic updating of meta tags and styles. It provides features like login functionality, session management, and error handling. Remix is a server-rendered framework that can enhance sites with JavaScript but doesn't require it for basic functionality. It aims to create quality HTML-driven documents and is flexible for use with different web technologies and stacks.
Acelerando tu aplicación React con menos JavaScript
React Summit 2023React Summit 2023
32 min
Acelerando tu aplicación React con menos JavaScript
Top Content
Mishko, the creator of Angular and AngularJS, discusses the challenges of website performance and JavaScript hydration. He explains the differences between client-side and server-side rendering and introduces Quik as a solution for efficient component hydration. Mishko demonstrates examples of state management and intercommunication using Quik. He highlights the performance benefits of using Quik with React and emphasizes the importance of reducing JavaScript size for better performance. Finally, he mentions the use of QUIC in both MPA and SPA applications for improved startup performance.
Documentación Full Stack
JSNation 2022JSNation 2022
28 min
Documentación Full Stack
Top Content
The Talk discusses the shift to full-stack frameworks and the challenges of full-stack documentation. It highlights the power of interactive tutorials and the importance of user testing in software development. The Talk also introduces learn.svelte.dev, a platform for learning full-stack tools, and discusses the roadmap for SvelteKit and its documentation.
SolidJS: ¿Por qué tanto Suspense?
JSNation 2023JSNation 2023
28 min
SolidJS: ¿Por qué tanto Suspense?
Top Content
Suspense is a mechanism for orchestrating asynchronous state changes in JavaScript frameworks. It ensures async consistency in UIs and helps avoid trust erosion and inconsistencies. Suspense boundaries are used to hoist data fetching and create consistency zones based on the user interface. They can handle loading states of multiple resources and control state loading in applications. Suspense can be used for transitions, providing a smoother user experience and allowing prioritization of important content.
De GraphQL Zero a GraphQL Hero con RedwoodJS
GraphQL Galaxy 2021GraphQL Galaxy 2021
32 min
De GraphQL Zero a GraphQL Hero con RedwoodJS
Top Content
Tom Pressenwurter introduces Redwood.js, a full stack app framework for building GraphQL APIs easily and maintainably. He demonstrates a Redwood.js application with a React-based front end and a Node.js API. Redwood.js offers a simplified folder structure and schema for organizing the application. It provides easy data manipulation and CRUD operations through GraphQL functions. Redwood.js allows for easy implementation of new queries and directives, including authentication and limiting access to data. It is a stable and production-ready framework that integrates well with other front-end technologies.
Tanstack Start - Un Framework de React de Full-Stack Primero del Lado del Cliente
React Summit US 2024React Summit US 2024
30 min
Tanstack Start - Un Framework de React de Full-Stack Primero del Lado del Cliente
Top Content
We surveyed thousands of developers to show that a louder audience leads to a better presentation. There has been a shift in web app development towards server-first architectures, which has improved full-stack capabilities but at the cost of complexity and divergence from the client-centric approach. Tanstec Start is a meta-framework that aims to provide the best client-side authoring experience with powerful server-side primitives. The Tansec Router supports advanced routing features, URL state management, and JSON storage. Combined with the server-side rendering capabilities of TanStack Start, it becomes even more powerful. The TanStack Router has isomorphic loaders and integrates seamlessly with TanStack Query for additional features like polling and offline support. UseSuspenseQuery allows for dynamic streaming of data during SSR. TanStack Start also offers server-side features, API routes, server functions, and middleware. The future plans include RSCs, websockets, real-time primitives, and static pre-rendering. TanStack Start is now in beta and is suitable for building React apps. It is open source.

Workshops on related topic

Construyendo aplicaciones web que iluminan Internet con QwikCity
JSNation 2023JSNation 2023
170 min
Construyendo aplicaciones web que iluminan Internet con QwikCity
WorkshopFree
Miško Hevery
Miško Hevery
Construir aplicaciones web instantáneas a gran escala ha sido elusivo. Los sitios del mundo real necesitan seguimiento, análisis y interfaces y interacciones de usuario complejas. Siempre comenzamos con las mejores intenciones pero terminamos con un sitio menos que ideal.
QwikCity es un nuevo meta-framework que te permite construir aplicaciones a gran escala con un rendimiento de inicio constante. Veremos cómo construir una aplicación QwikCity y qué la hace única. El masterclass te mostrará cómo configurar un proyecto QwikCity. Cómo funciona el enrutamiento con el diseño. La aplicación de demostración obtendrá datos y los presentará al usuario en un formulario editable. Y finalmente, cómo se puede utilizar la autenticación. Todas las partes básicas para cualquier aplicación a gran escala.
En el camino, también veremos qué hace que Qwik sea único y cómo la capacidad de reanudación permite un rendimiento de inicio constante sin importar la complejidad de la aplicación.
De vuelta a las raíces con Remix
React Summit 2023React Summit 2023
106 min
De vuelta a las raíces con Remix
Workshop
Alex Korzhikov
Pavlik Kiselev
2 authors
La web moderna sería diferente sin aplicaciones ricas del lado del cliente respaldadas por potentes frameworks: React, Angular, Vue, Lit y muchos otros. Estos frameworks se basan en JavaScript del lado del cliente, que es su núcleo. Sin embargo, existen otros enfoques para el renderizado. Uno de ellos (bastante antiguo, por cierto) es el renderizado del lado del servidor completamente sin JavaScript. Descubramos si esta es una buena idea y cómo Remix puede ayudarnos con ello?
Prerrequisitos- Buen entendimiento de JavaScript o TypeScript- Sería útil tener experiencia con React, Redux, Node.js y escribir aplicaciones FrontEnd y BackEnd- Preinstalar Node.js, npm- Preferimos usar VSCode, pero también se pueden utilizar IDE en la nube como codesandbox (otros IDE también están bien)
¿Deberíamos tener lógica de negocio en la interfaz de usuario?
JSNation 2022JSNation 2022
148 min
¿Deberíamos tener lógica de negocio en la interfaz de usuario?
Workshop
Samuel Pinto
Samuel Pinto
¿Cuántas veces has dicho o escuchado 'esta es lógica de negocio, no debería estar aquí'?En este masterclass, crearemos una aplicación frontend moderna utilizando patrones antiguos y aprenderás cómo construir aplicaciones que tengan una interfaz de usuario y servicios desacoplados.Comenzaremos con una aplicación React que tiene toda su lógica en la interfaz de usuario. Luego, paso a paso, extraeremos las reglas y operaciones para alcanzar ese punto óptimo de independencia.
Deja que la IA sea tu Documentación
JSNation 2024JSNation 2024
69 min
Deja que la IA sea tu Documentación
Workshop
Jesse Hall
Jesse Hall
Únete a nuestro masterclass dinámico para crear un portal de documentación impulsado por IA. Aprende a integrar ChatGPT de OpenAI con Next.js 14, Tailwind CSS y tecnología de vanguardia para ofrecer soluciones de código e resúmenes instantáneos. Esta sesión práctica te equipará con el conocimiento para revolucionar la forma en que los usuarios interactúan con la documentación, convirtiendo las búsquedas tediosas en descubrimientos eficientes e inteligentes.
Aspectos destacados:
- Experiencia práctica en la creación de un sitio de documentación impulsado por IA.- Comprensión de la integración de la IA en las experiencias de usuario.- Habilidades prácticas con las últimas tecnologías de desarrollo web.- Estrategias para implementar y mantener recursos de documentación inteligente.
Tabla de contenidos:- Introducción a la IA en la documentación- Configuración del entorno- Construcción de la estructura de documentación- Integración de ChatGPT para documentación interactiva
Aprende Fastify Un Plugin a la Vez
Node Congress 2021Node Congress 2021
128 min
Aprende Fastify Un Plugin a la Vez
Workshop
Matteo Collina
Matteo Collina
Fastify es un marco de trabajo HTTP para Node.js que se enfoca en brindar una buena experiencia de desarrollo sin comprometer las métricas de rendimiento. Lo que hace especial a Fastify no son sus detalles técnicos, sino su comunidad, que está abierta a contribuciones de cualquier tipo. Parte de la fórmula secreta es la arquitectura de plugins de Fastify, que permite a los desarrolladores escribir más de cien plugins.Este masterclass práctico está estructurado en una serie de ejercicios que cubren desde lo básico, como "hola mundo", hasta cómo estructurar un proyecto, realizar acceso a bases de datos y autenticación.

https://github.com/nearform/the-fastify-workshop
Construye una página de producto con el marco de trabajo Hydrogen de Shopify
React Advanced 2022React Advanced 2022
81 min
Construye una página de producto con el marco de trabajo Hydrogen de Shopify
Workshop
David Witt
David Witt
Sumérgete en Hydrogen, un marco de trabajo basado en React para construir tiendas en línea sin cabeza. Hydrogen está diseñado para el comercio de Shopify con todas las características que necesitas para una tienda en línea lista para producción. Proporciona un inicio rápido y un entorno de desarrollo rápido para que puedas centrarte en lo divertido: construir experiencias de comercio únicas. En este masterclass, crearemos una nueva tienda en línea y construiremos rápidamente una página de producto. Cubriremos cómo empezar, enrutamiento basado en archivos, obtener datos de la API de Storefront, los componentes integrados de Hydrogen y cómo aplicar estilos con Tailwind.Aprenderás:- Empezar con la plantilla hello-world en StackBlitz- Enrutamiento basado en archivos para crear una ruta /productos/ejemplo- Enrutamiento dinámico /productos/:handle- Consultar la API de Storefront con GraphQL- Mover la consulta dentro de la aplicación de Hydrogen- Actualizar la consulta para obtener un producto por su identificador- Mostrar título, precio, imagen y descripción.- Estilizado con Tailwind- Selector de variantes y botón de compra ahora- Bonus si hay tiempo: página de colecciones
Requisitos previos: - Un navegador basado en Chromium (StackBlitz)- Idealmente experiencia con React. Un conocimiento general de desarrollo web también es válido.