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

Rate this content
Bookmark

Vamos a ser sinceros, React es una forma de construir aplicaciones orientadas a componentes. Técnicamente, todos estamos haciendo desarrollo orientado a componentes. Pero, ¿realmente nuestros componentes están aislados, compuestos y probados en aislamiento o todavía están un poco acoplados entre sí? Echemos un vistazo a cómo puedes ser realmente orientado a componentes para poder construir, escalar y reutilizar componentes de React en todas tus aplicaciones de React.

20 min
25 Oct, 2021

Video Summary and Transcription

React fue creado para el desarrollo orientado a componentes. Los desafíos de compartir componentes incluyen la incapacidad de compartir fácilmente componentes entre aplicaciones. Los monorepos tienen beneficios pero también pueden presentar desafíos como el rendimiento lento del IDE y conflictos de fusión. La integración de nuevos desarrolladores y el proceso de implementación pueden llevar mucho tiempo. Bit resuelve estos desafíos al permitir componentes aislados y versionados en un monorepo, proporcionando una búsqueda fácil de componentes, filtrado y versionado, y habilitando el desarrollo orientado a componentes.

Available in English

1. Introducción al Desarrollo Orientado a Componentes

Short description:

React fue creado para el desarrollo orientado a componentes. Nos estamos moviendo hacia una web orientada a componentes. Así es como estamos construyendo actualmente.

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

2. Desafíos de Compartir Componentes

Short description:

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? Tenemos esta increíble aplicación y todos estos componentes. ¿Qué hacemos? 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.

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.

3. Desafíos de los Monorepos

Short description:

Los Monorepos permiten escalar aplicaciones, mejorar la velocidad y habilitar el intercambio de código. Sin embargo, pueden surgir limitaciones de herramientas, rendimiento lento de IDE, conflictos de fusión y problemas de visibilidad. Realizar cambios en la API en un Monorepo puede ser desafiante debido a la falta de visibilidad en el uso de componentes.

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.

4. Desafíos de la Incorporación y Despliegue

Short description:

Incorporar a los desarrolladores puede ser difícil. Sería mejor separar el código para los nuevos desarrolladores. El ciclo de retroalimentación y el proceso de despliegue pueden llevar mucho tiempo.

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.

5. Desafíos de las Herramientas Monorepo

Short description:

Los Monorepos no tienen límites, lo que lleva a tiempos de compilación largos. El problema es la herramienta, no el Monorepo en sí. Las personas desean la capacidad de compartir componentes fácilmente, tener tiempos de compilación más rápidos y ser dueños de sus propias características. También desean herramientas consistentes y bases de código desacopladas y simples. Bit resuelve estos problemas al permitir componentes aislados y versionados en un Monorepo.

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.

6. Componente Aislamiento y Propiedad

Short description:

Los componentes se pueden utilizar en cualquier aplicación o biblioteca. Los equipos pueden ser dueños e implementar sus propios componentes. Bit proporciona documentación, un playground en vivo e integración con Figma para los componentes. Permite una fácil visibilidad, descubrimiento y búsqueda en varios ámbitos.

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.

7. Búsqueda, Filtrado y Versionado de Componentes

Short description:

Puedo buscar y encontrar el componente que quiero, filtrar por dependencias específicas, tamaño y etiquetas. Una vez seguro, puedo instalarlo en cualquiera de mis componentes o aplicaciones. Creamos un componente de entorno para definir estándares y herramientas para todos los componentes. Las versiones independientes nos permiten elegir qué versión usar y cuándo actualizar. Podemos visualizar el grafo de dependencias de nuestros componentes. Queremos hacer que los componentes sean aislados y reutilizables en cualquier aplicació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.

8. Desarrollo impulsado por componentes con BIT

Short description:

Los componentes deben estar aislados, tener versiones independientes y poder utilizarse fácilmente en cualquier aplicación o componente. Construir con BIT simplifica el desarrollo impulsado por componentes.

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 ♪

Check out more articles and videos

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

React Advanced Conference 2021React Advanced Conference 2021
47 min
Design Systems: Walking the Line Between Flexibility and Consistency
Top Content
Design systems aim to bring consistency to a brand's design and make the UI development productive. Component libraries with well-thought API can make this a breeze. But, sometimes an API choice can accidentally overstep and slow the team down! There's a balance there... somewhere. Let's explore some of the problems and possible creative solutions.
React Summit 2022React Summit 2022
17 min
Composition vs Configuration: How to Build Flexible, Resilient and Future-proof Components
Top Content
There are many ways of authoring components in React, and doing it right might not be that easy, especially when components get more complex. In this talk, you will learn how to build future-proof React components. We will cover two different approaches to building components - Composition and Configuration, to build the same component using both approaches and explore their advantages and disadvantages.
React Advanced Conference 2021React Advanced Conference 2021
21 min
Building Cross-Platform Component Libraries for Web and Native with React
Top Content
Building products for multiple platforms such as web and mobile often requires separate code-based despite most of the components being identical in look and feel. Is there a way where we could use shared React component library on different platforms and save time? In this presentation I'll demonstrate one way to build truly cross-platform component library with a unique approach of using React & React Native in combination.
React Summit 2022React Summit 2022
27 min
Walking the Line Between Flexibility and Consistency in Component Libraries
Design systems aim to bring consistency to a brand's design and make the UI development productive. Component libraries with well thought API can make this a breeze. But, sometimes an API choice can accidentally overstep and slow the team down! There's a balance there... somewhere. Let's explore some of the problems and possible creative solutions.

Workshops on related topic

React Summit 2023React Summit 2023
137 min
Build a Data-Rich Beautiful Dashboard With MUI X's Data Grid and Joy UI
WorkshopFree
Learn how to put MUI’s complete ecosystem to use to build a beautiful and sophisticated project management dashboard in a fraction of the time that it would take to construct it from scratch. In particular, we’ll see how to integrate the MUI X Data Grid with Joy UI, our newest component library and sibling to the industry-standard Material UI.
Table of contents:- Introducing our project and tools- App setup and package installation- Constructing the dashboard- Prototyping, styling, and themes - Joy UI features- Filtering, sorting, editing - Data Grid features- Conclusion, final thoughts, Q&A
React Summit 2022React Summit 2022
147 min
Hands-on with AG Grid's React Data Grid
WorkshopFree
Get started with AG Grid React Data Grid with a hands-on tutorial from the core team that will take you through the steps of creating your first grid, including how to configure the grid with simple properties and custom components. AG Grid community edition is completely free to use in commercial applications, so you'll learn a powerful tool that you can immediately add to your projects. You'll also discover how to load data into the grid and different ways to add custom rendering to the grid. By the end of the workshop, you will have created an AG Grid React Data Grid and customized with functional React components.- Getting started and installing AG Grid- Configuring sorting, filtering, pagination- Loading data into the grid- The grid API- Using hooks and functional components with AG Grid- Capabilities of the free community edition of AG Grid- Customizing the grid with React Components
TypeScript Congress 2023TypeScript Congress 2023
131 min
Practice TypeScript Techniques Building React Server Components App
Workshop
In this hands-on workshop, Maurice will personally guide you through a series of exercises designed to empower you with a deep understanding of React Server Components and the power of TypeScript. Discover how to optimize your applications, improve performance, and unlock new possibilities.
 
During the workshop, you will:
- Maximize code maintainability and scalability with advanced TypeScript practices
- Unleash the performance benefits of React Server Components, surpassing traditional approaches
- Turbocharge your TypeScript with the power of Mapped Types
- Make your TypeScript types more secure with Opaque Types
- Explore the power of Template Literal Types when using Mapped Types
 
Maurice will virtually be by your side, offering comprehensive guidance and answering your questions as you navigate each exercise. By the end of the workshop, you'll have mastered React Server Components, armed with a newfound arsenal of TypeScript knowledge to supercharge your React applications.
 
Don't miss this opportunity to elevate your React expertise to new heights. Join our workshop and unlock the potential of React Server Components with TypeScript. Your apps will thank you.
React Summit 2023React Summit 2023
31 min
From Idea to Production: React Development with a Visual Twist
WorkshopFree
Join us for a 3-hour workshop that dives into the world of creative React development using Codux. Participants will explore how a visually-driven approach can unlock creativity, streamline workflows, and enhance their development velocity. Dive into the features that make Codux a game-changer for React developers. The session will include hands-on exercises that demonstrate the power of real-time rendering, visual code manipulation, and component isolation all in your source code.
Table of the contents: - Download & Setup: Getting Codux Ready for the Workshop- Project Picker: Cloning and Installing a Demo Project- Introduction to Codux Core Concepts and Its UI- Exercise 1: Finding our Feet- Break- Exercise 2: Making Changes While Staying Effective- Exercise 3: Reusability and Edge Case Validation- Summary, Wrap-Up, and Q&A
React Summit 2022React Summit 2022
98 min
Crash Course into TypeScript for content from headless CMS
WorkshopFree
In this workshop, I’ll first show you how to create a new project in a headless CMS, fill it with data, and use the content in your project. Then, we’ll spend the rest of time in code, we will:- Generate strongly typed models and structure for the fetched content.- Use the content in components- Resolve content from rich text fields into React components- Touch on deployment pipelines and possibilities for discovering content-related issues before hitting production
You will learn:- How to work with content from headless CMS- How content model can be leveraged to generate TS types and what benefits it brings to your project- How not to use string literals for content in code anymore- How to do rich text resolution into React components- How to minimize or avoid content-related issues before hitting production