Llevando el Desarrollo Orientado a Componentes un Paso Más Allá

♪♪ Llevando el desarrollo orientado a componentes un paso más allá... Hola a todos, mi nombre es Devi O'Brien, soy la Jefa de Defensoría del Desarrollador en Bit. También soy una Estrella de GitHub y MVP de Microsoft, Experta en Desarrollo de Google y Experta en Desarrollo de Medios. Y puedes seguirme en Twitter en devs underscore O'Brien. Así que empecemos.

¿Cómo va todo, y ups, me he robado completamente las diapositivas de Matt Billman, el CEO de Netlify. Me he robado sus diapositivas de su charla principal. Lo siento, Matt. Lo que él dijo es cómo va todo. Número uno, dijo que los monolitos se están moviendo hacia las APIs. Número dos, Git ha transformado la web. Número tres, componentes. Número cuatro, pre-construcción en JS. Y lo que quiero que te enfoques es en el número tres, pensar en componentes. Y como él dijo, el mundo se está moviendo hacia un mundo orientado a componentes. Nos estamos moviendo hacia una web orientada a componentes, y realmente necesitamos que todos estemos pensando y trabajando en componentes. Ahora, es posible que ya estés diciendo, pero estoy construyendo en React, y tienes toda la razón. React fue creado para el desarrollo orientado a componentes. React fue creado para componentes. Y básicamente, lo que estamos haciendo es construir en componentes. Así que sí, si ya estás construyendo en React, estás haciendo un gran trabajo. Ahora estamos construyendo aplicaciones orientadas a componentes con React.

Genial. Entonces, ¿cuál es el problema? Esta es nuestra aplicación. Es increíble. Esta es mi hermosa tienda de zapatos, y he creado esta aplicación a partir de componentes. Entonces, ese componente de botón es en realidad solo un componente que se reutiliza dentro de ese componente de héroe en el interruptor de tema en la parte superior y también en la tarjeta de producto. Así que estamos construyendo en componentes, y así es como estamos construyendo actualmente. Y esto es genial. Esto es fantástico.

El problema es que los componentes no tienen valor fuera de la aplicación. Una vez que he construido esa aplicación, todos esos componentes quedan atrapados dentro de esa aplicación. Eso es un problema. Eso no está realmente haciendo que los componentes sean lo primero. ¿Sabes qué sucede cuando tenemos que construir múltiples aplicaciones? Ya sabes, llega el gerente de producto y dice que necesitamos construir otra aplicación. ¿Qué hacemos ahora? Tenemos esta increíble aplicación y todos estos componentes. ¿Qué hacemos?

Así que ahora tenemos tres aplicaciones y muchos de estos componentes son similares. Estamos construyendo una aplicación de comercio electrónico similar. Así que tenemos componentes grandes como ese carrito de compras. No quiero reconstruir ese componente una y otra vez. Quiero decir, sí, solo un botón simple, copiar y pegar, ponerlo ahí, y listo. ¿O no? Habrá inconsistencia en todas tus aplicaciones eventualmente. Especialmente si escalas y creces y creces. Así que realmente necesitas otra solución. Básicamente, quieres poder compartir fácilmente esos componentes entre esas aplicaciones. Y hay un par de opciones disponibles, por supuesto. Ya sabes, podrías simplemente empaquetarlos en NPM y esperar lo mejor. Quiero decir, hay mucho trabajo involucrado en eso. Es posible, pero es doloroso y no queremos dolor, ¿verdad? Así que hay un par de opciones, como dije.

Y uno de ellos es trabajar en monorepos. Ahora, mucha gente hace esto. Mucha gente está muy contenta trabajando en monorepos porque te permite escalar esas aplicaciones, poner muchas aplicaciones dentro de un solo repositorio. Y cuando haces eso, puedes mejorar la velocidad. Así que puedes construir más y más aplicaciones fácilmente porque tienes acceso a todo el código de cada una de esas aplicaciones.

Eso significa que puedes compartir código fácilmente y reutilizar cualquiera de esos componentes en cualquiera de las aplicaciones. Entonces, la experiencia de desarrollo es realmente buena, ¿verdad? Porque tienes acceso a todo, por lo que es fácil para ti simplemente, ya sabes, construir cosas a partir de cualquier cosa que esté en ese repositorio. Y si tienes que refactorizar alguno de esos componentes, bueno, también es bastante fácil porque, como dije, tienes acceso a ellos. Y la colaboración entre equipos, estás trabajando con todos los miembros del equipo en esto. Así que, ya sabes, es bastante bueno. Y tienes cierta estandarización porque solo tienes un repositorio que mantener. Así que todo se ejecuta con la misma estandarización. Así que este es un buen punto.

Desafortunadamente, con los monorepos, hay un par de problemas. Las herramientas no fueron creadas para los monorepos. Así que las herramientas realmente no están ahí. Tu IDE puede volverse lento porque tienes mucho código para cargar. Y, ya sabes, tienes que hacer pull, push otra vez. Va a ser bastante lento porque tienes mucho que descargar. Cuando tus equipos se hacen más grandes y más grandes y más personas están haciendo cambios en esa rama principal, tienes todos esos conflictos de fusión con los que lidiar. Y constantemente estás incorporando esos nuevos cambios.

Visibilidad y descubrimiento, esto puede ir en ambos sentidos, ¿verdad? Porque podrías decir, oh, en un monorepo, puedo ver todos esos componentes que están disponibles para mí. Y puedes, puedes ver todo el código. Pero realmente no puedes ver cómo se ve el componente. Tendrías que, como, ¿en qué aplicación se está usando? Y tendrías que tratar de encontrar esa aplicación para ver cómo se ve y tratar de descubrirlo y visualizarlo realmente. Y tienes que hacer cambios graduales en la API, porque si comienzas a modificar la API, ni siquiera sabes qué componente está usando esa API. Entonces ese componente está siendo utilizado por otro. ¿Está siendo utilizado por qué aplicación? Así que es realmente difícil ver dónde se está usando. Y vas a romperle algo a alguien más simplemente modificando las props, modificando la API de ese componente? Probablemente. Eso no es bueno.

Eso no es bueno. Incorporar a los desarrolladores puede ser, ya sabes, bastante difícil. Traes a un nuevo desarrollador, y le das esta enorme base de código, y le dices, buena suerte, a nadar. Encuentra el código. Descúbrelo. ¿Sabes qué? ¿Y si simplemente lo separas para que un nuevo desarrollador solo tenga que preocuparse por el código que tiene que preocuparse? Eso sería mucho mejor, ¿verdad? Y el ciclo de retroalimentación puede llevar mucho tiempo, porque tiene que pasar por un proceso así, y cuando finalmente llega a producción después de que todos los demás hayan terminado de construir lo que están construyendo, y tal vez despliegues en este momento, en un día específico, ya sabes, una vez que se despliega, hay un largo tiempo de espera, cuando realmente solo quieres, ya sabes, hacer un cambio y desplegarlo, ¿verdad? ¿Por qué no podemos hacer eso? Límites y propiedad del equipo.

Quiero decir, no hay límites, ¿verdad? Todos están trabajando en el mismo código base. Quiero decir, podrías decir, no toques esa carpeta que pertenece a ese equipo, pero eso es bastante difícil, ¿verdad? No hay nadie que lo controle. Así que no hay límites reales. Y los tiempos de compilación pueden ser bastante largos, porque tienes que compilar, no solo esa aplicación, sino todas las aplicaciones en ese Monorepo y todos esos componentes.

Entonces, ¿a la gente realmente le gusta trabajar con monorepos? ¿Los odian? ¿Los aman? Eso es lo que pregunté. ¿Y sabes qué? El problema en realidad es la herramienta. El problema no es el Monorepo. Los Monorepos son una excelente forma de pensar en cómo hacer las cosas, pero las herramientas simplemente no han ayudado, como dice Oliver, o como dice Garret, herramientas malas. Incluso Brandon, le encanta el hecho de que se puede compartir código entre aplicaciones y bibliotecas, visibilidad, colaboración, consistencia, capacidad de estandarizar, versiones de paquetes individuales, pero odia las herramientas insuficientes. Esto es lo que hace que la experiencia sea mala, conduce a CI inflado y un montón de scripts ad-hoc.

Entonces, ¿cómo podemos solucionar esto? ¿Cómo podemos mejorarlo? Sabes, ¿qué es lo que la gente quiere? Eso es lo que debemos analizar. ¿Qué problema estamos tratando de resolver aquí? Lo que la gente quiere es la capacidad de compartir componentes. Quieren poder empaquetar fácilmente, gestionar sus componentes. No quieren tener conflictos de versiones o romperse entre sí. Quieren tiempos de compilación más rápidos. Quieren construir solo lo que están construyendo y lanzarlo sin tener que preocuparse por lo que están haciendo los demás. Quieren límites y propiedad del equipo. Entonces quieren ser dueños de su propia característica, sus propios componentes, y trabajar solo en eso y dejar todo lo demás como si no existiera. Y quieren herramientas consistentes. Quieren que todos esos componentes se construyan con un tipo similar de herramientas para que todos se construyan como deberían y se vean iguales en todas esas aplicaciones. Y realmente, realmente quieren bases de código desacopladas y simples. Así que solo tienen que preocuparse por el código en el que realmente tienen que preocuparse. Entonces, ¿no estamos pidiendo mucho?

Bueno, en realidad, bienvenido a Bit. Bit es una herramienta para el desarrollo basado en componentes. Y con Bit, muchos de estos problemas se resuelven debido a cómo Bit te permite trabajar con componentes. Si quieres trabajar en un Monorepo, puedes hacerlo con Bit. Simplemente puedes tener tus componentes de IU base, componentes de comercio electrónico y componentes de tu tienda o componentes de tu aplicación, todo en un solo Monorepo. La diferencia es que cada componente está completamente aislado y versionado. Y por lo tanto, es como su propio pequeño repositorio, supongo. Cada componente está aislado, lo que significa que se puede usar en cualquiera de esas aplicaciones o en cualquiera de esas otras bibliotecas.

Cada componente está aislado, lo que significa que se puede utilizar en cualquiera de esas aplicaciones o en cualquiera de esas otras bibliotecas. Ahora también puedes tener una base de código simple y desacoplada. Así que literalmente puedes decir, está bien, lo voy a separar porque sabes que estás escalando, el equipo está creciendo, y quieres que los equipos sean dueños de las características. Entonces puedes tener un equipo, base UI, este es tu repositorio y estos son tus componentes. Eres responsable de esto y construyes tus componentes e implementas tus componentes cuando quieras. Equipo de E-commerce, aquí están tus componentes, construye tus componentes, implementa tus componentes y trabaja donde y cuando quieras. Y luego tus aplicaciones, podría haber otro equipo que sea dueño de aplicaciones específicas y pueden implementar sus componentes en su aplicación cuando lo deseen. A medida que Bit versiona cada componente y lo aísla luego se puede utilizar en cualquiera de esos repositorios, instalado en cualquiera de esos y básicamente utilizado en cualquier repositorio.

Aquí tienes un ejemplo, esta es mi base UI, base de código y VS code y puedes ver en la línea dos, estoy importando el botón como un componente de este repositorio real, ¿verdad? Del repositorio base UI, así que lo estoy importando en lugar de usar una importación local porque cada componente está, ya sabes, versionado y aislado, necesito instalarlo básicamente como si fuera su propio paquete. Así que estoy instalando este botón y usándolo dentro de este componente de interruptor de equipo. Ahora en mi aplicación de E-commerce, o en realidad esto no es una aplicación, son solo un montón de componentes de E-commerce, pero en este repositorio de E-commerce, en realidad estoy instalando ese mismo componente de botón. Así que aquí estoy instalando el base UI desde el repositorio base UI, el botón, la tarjeta, el encabezado y algunos otros vienen de un repositorio diferente, el que acabo de mostrarte y también está instalando algunos componentes de este repositorio en particular, del repositorio de E-commerce. Así que puedo instalar componentes de cualquier repositorio dentro de cualquiera de mis repositorios y espacios de trabajo. Esto me permite tener propiedad del equipo. Tengo mi equipo de base UI que es dueño de esos componentes, dueño de ese repositorio, tengo mi equipo de E-commerce que es dueño de esos y luego tengo mi tienda de perfumes, mi tienda de zapatos, mis tiendas de deportes, diferentes equipos que son dueños de esas aplicaciones. Y en todo momento, puedo ver qué componentes están utilizando cuáles. Puedo ver que el base UI está siendo utilizado por el E-commerce y también está siendo utilizado por estas tiendas y el E-commerce es utilizado por estos otros y puedo ver en todo momento, quién está utilizando a quién, quién depende de quién, quiénes son sus dependientes.

Ahora, cada componente en Bit, viene con alguna documentación y un playground en vivo. Así que en todo momento, puedes ver un componente, ver qué hace, leer sobre él, entenderlo básicamente diciendo, este es el componente que quiero y puedes jugar con él y ver, así que puedo cambiar cualquier cosa en esto y cambiará en vivo. Puedo actualizar ese texto, puedo ver cómo se ve con un texto más largo, con el texto roto, qué pasa si agrego un precio muy largo, etcétera, etcétera. También puedo incrustar los diseños de Figma, directamente dentro de la documentación de mi componente, lo que significa que en todo momento, puedo ver cómo debería verse mi componente según el diseño, y simplemente puedo hacer clic en esa incrustación de Figma y se abrirá el archivo de Figma directamente, donde luego puedo explorar aún más el relleno y el espaciado que el diseñador creó para ese componente en particular. Puedo crear diferentes estados de los componentes, diferentes composiciones y ver cómo se ve el componente si agrego algo específico allí, lo elimino y lo cambio, lo modifico, etcétera. Y puedo ver las propiedades del componente, es decir, la API del componente, puedo ver que este componente acepta un texto de botón, lo que significa que sé que puedo cambiar ese texto de `agregar al carrito` a lo que quiera. Puedo cambiar el precio, pero como puedo ver desde aquí, no puedo cambiar la moneda, así que tengo que trabajar en dólares si quiero trabajar con este componente. Puedo cambiar la fuente y la etiqueta alt para la imagen y puedo cambiar el texto, así que en todo momento puedo ver a qué tengo acceso, cuáles son los tipos también, y una descripción de lo que estas propiedades van a hacer. Ahora puedo tener fácilmente visibilidad y descubribilidad de mis componentes. Puedo buscar un componente. Por ejemplo, estoy buscando una tarjeta de producto, quiero ver si existe, y básicamente puedo buscar y aquí puedo ver que tengo una entidad de producto o tengo una tarjeta de producto o tengo un precio que está en la carpeta de productos, así que puedo ver que estoy buscando la tarjeta de producto y también tengo una cuadrícula de tarjetas de producto, así que esto me da una idea de lo que está disponible para mí. Ahora también puedo buscar en varios ámbitos o varios informes, así que aquí están mis componentes. Tengo componentes de base UI, tengo varios ámbitos aquí como el E-commerce, la tienda de zapatos, etcétera, y simplemente puedo buscar en eso y puedo buscar un botón.

No tengo que preocuparme por saber si ese botón pertenece a la base UI o si pertenece a E-commerce. Simplemente puedo buscar y encontrar el componente que quiero y puedo ver aquí, ¿quiero un botón de React, un botón de UI, un botón de TypeScript? ¿Qué tipo de botón estoy buscando aquí? Luego puedo filtrar mi componente por dependencias específicas. Por ejemplo, es posible que no quiera usar una dependencia específica en mi proyecto o tal vez quiera una, así que puedo filtrar por, ¿estamos usando Testing Library React, por ejemplo, porque eso es lo que quiero usar para mis pruebas o quiero asegurarme de que eso se instale en mi proyecto? Puedo filtrarlo por tamaño. Tal vez estoy buscando un componente específicamente pequeño y lo mismo con las etiquetas y otras cosas. Ahora puedo usar mi componente en cualquier lugar. Una vez que estoy seguro de que este es un componente que quiero usar, puedo simplemente usar bit, NPM o Yarn y puedo instalarlo en cualquiera de mis componentes o en cualquiera de mis aplicaciones, sin importar dónde estén.

Ahora, también podemos tener herramientas consistentes y estándar para todos nuestros componentes. Lo que hacemos aquí es crear un entorno. Ahora, un entorno también es un componente. Entonces, al crear un componente de entorno, podemos definir básicamente las reglas y las herramientas que queremos para nuestros componentes. Así que podemos tener nuestras reglas de prettier, nuestras reglas de ESLint, nuestra configuración de JS, nuestra configuración de TS, nuestra configuración de Webpack, etcétera, etcétera, etcétera. Y simplemente creamos un componente con todos estos estándares que queremos definir. Y luego lo aplicamos a todos nuestros componentes a medida que construimos esos componentes. Y luego, si queremos modificarlo, agregar otra regla, cambiar algo, simplemente lo hacemos una vez en el componente de entorno y luego se actualizará en todos esos componentes una vez que lo importemos en ese repositorio.

Entonces, podemos tener versiones independientes para todos nuestros componentes. Aquí tenemos nuestra tarjeta de producto y tenemos la última versión, que es la versión 1.0.13, y básicamente podemos retroceder en el tiempo en cualquier momento y podemos ver el estado de ese componente, uno atrás o 10 atrás o cero cero, lo que sea, y podemos ver cómo se vería, qué ha cambiado, y podemos decidir qué versión del componente queremos usar. Ahora, si estamos trabajando en un espacio de trabajo y modificamos el componente de precio, por ejemplo, de la tarjeta de producto, entonces la tarjeta de producto se autotipeará y se creará automáticamente una nueva versión porque el componente de precio en el que depende se modificó. Ahora, si estás trabajando en otra aplicación y otro repositorio, y esa tarjeta de producto obtiene una nueva versión, no vas a romper tu aplicación ni nada porque tú decides si quieres usar la última versión o no. Básicamente, te dirá que hay una nueva versión. ¿Quieres importar la nueva versión? Y puedes decir, en realidad, no, no estoy listo para actualizar esta versión porque no has terminado de actualizar el resto de la aplicación al nuevo tema, etcétera, etcétera. Así que siempre puedes elegir qué versión quieres, cuándo quieres actualizar y puedes tener múltiples versiones, diferentes versiones en diferentes aplicaciones si eso es lo que quieres. Y puedes ver qué está sucediendo en todo momento. Así que puedes ver tu componente y puedes ver que el componente de tarjeta de producto está usando la versión 2.0.1 del botón. Y puedes ver que está usando la tarjeta, el encabezado, la imagen, el texto, los colores disponibles y el componente de moneda y en qué versión se encuentran todos ellos. Así que en todo momento puedes visualizar el grafo de dependencias de tu componente. Básicamente, queremos reutilizar componentes en cualquier aplicación. Esto es lo que estamos tratando de lograr. Queremos sacar los componentes de la aplicación y queremos hacer que los componentes sean aislados. Queremos hacer que los componentes sean sus propias entidades específicas, como si dijeras que eres un componente y vives donde quieras.

En este momento vas a vivir en el repositorio de base UI y en el repositorio de e-commerce o lo que sea, pero eso no es importante. Lo importante es que estés aislado y tengas versiones independientes. Puedes ser lanzado de forma independiente y puedes ser instalado en cualquier aplicación, en cualquier otro componente, lo que sea. Puedes ser utilizado fácilmente en todo momento. Y esto es lo que quieres. Quieres hacer que el componente sea el número uno. Esto es lo que llamamos desarrollo impulsado por componentes. Y básicamente esto es lo que todos deberíamos estar haciendo. Deberíamos estar construyendo webs impulsadas por componentes, aplicaciones impulsadas por componentes, todo impulsado por componentes. Y construir con BIT va a hacer eso más fácil. Así que te animo mucho a que pruebes BIT, lo pruebes y empieces a pensar en componentes, a construir con componentes y a construir una web mejor. Muchas gracias a todos. Si quieres ver las demos de BIT que mostré en la tienda de zapatos, etc., solo tienes que ir a bit.dev/learn-bit.react y podrás ver todos esos componentes que acabo de mostrarte. O puedes ir a github.com/bit-demos y verás todos esos repositorios individuales y verás cómo se utilizan los componentes en todos estos repositorios. Consulta nuestra documentación para obtener más información, hay videos y todo tipo de cosas allí. Y, por supuesto, puedes seguirme en Twitter en devs_brian. Si tienes alguna pregunta, si quieres jugar un poco más con BIT y tienes algún comentario para nosotros, los mensajes directos siempre están abiertos, así que diviértete construyendo componentes, construyendo aplicacionesreact, y haciendo que los componentes sean el número uno y los componentes simplemente se utilizarán en todas esas aplicaciones, donde sea, tantas como quieran, donde sea que estén. Y eso es todo, muchas gracias, adiós. ♪ Música dramática ♪