Desarrollo escalable de React para proyectos grandes

Rate this content
Bookmark

Escalar el desarrollo de React en múltiples equipos puede ser increíblemente difícil. Los equipos necesitan compartir funcionalidades centrales mientras se mantienen autónomos. Los cambios deben propagarse a través de muchos proyectos mientras se prueban. Nx es un conjunto de herramientas de código abierto que permite a las organizaciones escalar el desarrollo de manera más fácil que antes. ¡Nx facilita la configuración de Cypress, Prettier, Storybook, Next.js y Gats más rápido que nunca! También puedes desarrollar aplicaciones full-stack utilizando frameworks de Node como Apollo y Nest.js y compartir código entre el frontend y el backend. En esta charla aprenderás cómo grandes organizaciones como Facebook, Microsoft y Google pueden escalar con éxito a través de múltiples equipos, unidades de negocio y productos.

35 min
02 Aug, 2021

Video Summary and Transcription

Desarrollo escalable de React facilitado por NX, un enfoque basado en monorepo utilizado por grandes empresas de tecnología. Los desafíos de compartir código en múltiples repositorios incluyen herramientas duplicadas, flujos de trabajo separados y conflictos de versiones. Los beneficios de un monorepo incluyen herramientas unificadas, una única versión de dependencias y un desarrollo simplificado. NX permite flujos de trabajo de monorepo con sistemas de construcción inteligentes y fácil intercambio de código. También admite la generación de código personalizado, impone estándares y dependencias, mejora los tiempos de construcción y proporciona herramientas y complementos modernos.

Available in English

1. Introducción al Desarrollo React Escalable con NX

Short description:

Hola a todos. Mi nombre es Jason. Estoy aquí para hablarles sobre el desarrollo React escalable facilitado por NX. Les presentaré el concepto de un monorepo y explicaré por qué es beneficioso. Los monorepos son utilizados por Facebook, Microsoft, Google y otras grandes empresas de tecnología para desarrollar e implementar código de forma independiente.

Hola a todos. Mi nombre es Jason. Estoy aquí para hablarles sobre el desarrollo escalable de React facilitado por NX. Primero, voy a hacer una introducción sobre mí mismo, y también voy a presentar el concepto de un monorepo, y luego voy a profundizar más en lo que es NX y cómo puede ayudarte a escalar tu desarrollo de React. Luego haremos una demostración en vivo al final, si tenemos tiempo. Así que empecemos.

Un poco sobre mí, pueden encontrarme en Twitter como Fersenpandas. Soy arquitecto en Narwal. Y también soy parte del equipo principal de NX. Trabajo en NX como parte de mi trabajo a tiempo completo. En Narwal, asesoramos a empresas Fortune 500. Somos expertos en desarrollo de código en monitoreo, y también creamos herramientas de desarrollo para acelerar el desarrollo de código en monitoreo. Así que mi trabajo consiste en acelerar el trabajo de las empresas de manera más rápida y eficiente. Y ahí es donde entra NX.

Pero antes de hablar sobre NX, permítanme contarles un poco sobre los monorepos. Primero quiero decir lo que no es un monorepo, porque hay muchas ideas equivocadas. Luego les diré qué es y por qué alguien podría querer usar un monorepo. Una idea equivocada sobre un monorepo es que no es una aplicación monolítica. Esto significa que no tienes que construirlo todo de una vez. No tienes que construir una gran aplicación a partir de un monorepo. Y tampoco tienes que implementar todo el monorepo de una vez. Permítanme explicar más sobre qué es un monorepo, para que vean dónde está la idea equivocada. Un monorepo es simplemente un repositorio único que tiene múltiples proyectos, lo que significa que hay un fragmento de código que vive en un directorio, y otro fragmento de código que vive en otro directorio, pero todo está bajo un control de versiones. Lo veo como un almacén de código. En un almacén, tienes paquetes que están empaquetados por separado por diferentes personas. Se almacenan juntos en un almacén, pero luego se envían por separado a diferentes personas. Y lo mismo ocurre con los proyectos dentro de un monorepo. Se desarrollan de forma independiente en un repositorio, pero se implementan de forma independiente. ¿Quién utiliza monorepos? Facebook, Microsoft, Google, todos utilizan un monorepo, al igual que otras grandes empresas de tecnología. Y no creo que sea una coincidencia que muchas de estas exitosas empresas de tecnología hayan adoptado un enfoque de monorepo para el desarrollo.

2. Desarrollo de aplicaciones sin monorepos

Short description:

Veamos cómo desarrollamos aplicaciones sin monorepos. Tengo mi aplicación, pero también divido la funcionalidad en diferentes partes del código. Agrupo todo en un repositorio Git, configuro NPM, Jenkins o Travis, y trabajo en diferentes partes del código y la aplicación simultáneamente. Este flujo de trabajo es familiar para muchos.

Entonces, veamos por qué eligen hacerlo así. Veamos cómo desarrollamos aplicaciones sin monorepos. Así que, tengo mi aplicación, pero también divido la funcionalidad en diferentes partes del código, ¿verdad? Para que mi código esté organizado. Agrupo todo en un repositorio Git. Configuro NPM, y configuro Jenkins o Travis, y todo funciona en conjunto. Puedo trabajar en diferentes partes del código, así como en la aplicación misma al mismo tiempo. Y luego, puedo probar todo de una vez. Y este es un flujo de trabajo con el que muchas personas están familiarizadas.

3. Desafíos de Compartir Código en Múltiples Repositorios

Short description:

Pronto, necesitaremos compartir código entre diferentes aplicaciones dentro de nuestra organización. Esto se vuelve desafiante cuando todo está en un solo repositorio. Dividir el código en múltiples repositorios introduce herramientas duplicadas, flujos de trabajo separados y pérdida de contexto. Analizar las relaciones entre los repositorios se vuelve difícil y las versiones pueden desincronizarse, lo que lleva a confusión y conflictos.

Sin embargo, pronto necesitaremos compartir el código entre diferentes aplicaciones dentro de nuestra organización. No solo tenemos la aplicación de coche, sino que también podemos tener una API y una aplicación de tienda también. Y es posible que deseen acceder a partes del código que hemos escrito previamente para la aplicación de coche. Por lo tanto, esto es realmente difícil de hacer porque todo está en un solo repositorio y no puedes traer las partes del coche sin traer el coche completo.

Entonces, voy a hablar sobre cómo compartir código en múltiples repositorios, algo con lo que muchos de ustedes probablemente están acostumbrados, y esta será la forma más complicada de las dos. Así que, cuando te das cuenta de que quieres compartir código, decides que eso significa que tienes que dividir todo mi código en diferentes repositorios. Así que, sigues adelante y creas todos estos repositorios de Git y la gente trabaja en ellos. Esto inmediatamente introduce la necesidad de herramientas duplicadas. No solo tienes múltiples repositorios, también tienes múltiples flujos de CI, también tienes múltiples versiones de las dependencias de NPM y todo eso. Y para cada repositorio que configures, necesitas esto.

Junto con las herramientas duplicadas, también tienes que separar tu flujo de trabajo. Cuando trabajas en esta biblioteca aquí, solo puedes ejecutar esas pruebas porque las otras pruebas están en diferentes repositorios, así que estás limitado a ejecutar solo estas pruebas. Por lo tanto, no sabes si la aplicación de coche está rota o no, así que tienes que hacer algo de trabajo allí también. Luego puedes ejecutar esas pruebas, pero también te darás cuenta de que la API también depende de su biblioteca, así que tienes que hacer lo mismo allí. Y esto es como tres fases diferentes de tu flujo de trabajo, es muy discontinuo, y pierdes mucho contexto al cambiar de un lugar a otro. No como antes, donde podíamos trabajar en la aplicación de coche y en nuestra biblioteca al mismo tiempo. Pero, porque la gente quiere compartir código, esto es con lo que tenemos que lidiar.

Además, esas líneas claras que he dibujado entre estos proyectos son menos analizables cuando se utilizan múltiples repositorios. Los múltiples repositorios suelen estar vinculados a través de métodos como npm, a través de package.json y cosas así, y es realmente difícil poder analizarlos, por lo que esas líneas se vuelven menos visibles cuando miramos nuestra organización en su conjunto. Todo lo que sabemos es que tenemos, ya sabes, seis repositorios diferentes, pero esos están relacionados de maneras que no podemos analizar fácilmente a través del análisis de código. Luego, también podemos desincronizarnos. Muchas veces, cuando dividimos las cosas en diferentes repositorios, publicamos diferentes versiones, así que al principio, todo puede ser una versión 1. Funciona en conjunto. Es genial. Pero luego, en la biblioteca inferior aquí, podemos lanzar una segunda versión, ¿verdad?, que tiene algunos cambios, y otras bibliotecas tienen que incorporar esos cambios. Entonces, el de la derecha lo incorporará y se actualizará a la versión 2 de esta biblioteca inferior, pero la biblioteca de la izquierda elegirá hacerlo más tarde.

Así que, por ahora, se quedará en la versión 1. Y eso puede parecer una decisión aceptable en esta vista del mundo, pero cuando volvemos a nuestra organización, la aplicación de coche que utiliza ambas bibliotecas está muy confundida ahora sobre cuál es la versión correcta. Y lo más probable es que realmente traiga ambas versiones y nos encontramos en los días de jQuery donde hay tres versiones de jQuery en la página. Y esto también se aplica a las dependencias externas, como React.

4. Beneficios de un Monorepo

Short description:

Cuando diferentes repositorios dependen de diferentes versiones de React, puede llevar a confusión y complicaciones. Sin embargo, utilizando un monorepo, todo el código puede almacenarse en un solo repositorio, lo que proporciona herramientas unificadas, una única versión de dependencias y la capacidad de probar solo lo necesario. Este enfoque simplifica el desarrollo y beneficia a las personas dentro de la organización.

Cuando las cosas están en diferentes repositorios, pueden depender de diferentes versiones de React, y en nuestra organización, podríamos tener la versión 16, la versión 15 y la versión 0.14, todas al mismo tiempo. Y cada aplicación podría usar una versión diferente, lo que podría generar confusión sobre qué versión debería utilizar y cosas así. Así que hablemos de cómo podemos hacer esto de manera más fácil y menos complicada.

Utilizando un monorepo, almacenaríamos todo este código en un solo repositorio. Y sé lo que todos están pensando, que esto no es escalable, pero más adelante les mostraré que sí lo es. Una cosa que vemos es que nuestras tooling nuevamente están unificadas. Tenemos un repositorio, un flujo de CI y dependencias de npm. Además, esas dependencias que hemos dibujado ahora son muy analizables. Parecen importaciones de este archivo, de este archivo, y podemos ver qué proyectos dependen de otros proyectos. De esa manera, puedo trabajar en ambos al mismo tiempo. Puedo trabajar en mi biblioteca, puedo trabajar en mi aplicación y cuando lo subo para ver si mis cambios se ven bien, también puedo ejecutar el conjunto específico de pruebas que son suficientes para verificar que mi cambio es preciso y bueno. Por lo tanto, las otras bibliotecas a la izquierda de la pantalla no tienen que ejecutarse porque mis cambios no las afectan en absoluto. También hay una única versión de cada proyecto y todas sus dependencias. Así que simplemente avanzamos. Cada vez que cambias a una nueva rama, tienes la misma versión que funciona con todo. Esto también significa que puedes hacer commit en múltiples proyectos con un solo commit y no tienes que preocuparte por mantenerlo sincronizado con las versiones. Y lo mismo ocurre con React. Así que una vez que actualizamos a la versión 16 de React, todo nuestro repositorio y todas nuestras aplicaciones están en la versión 16.

Así que he pasado por mucha información. Retrocedamos un poco y repasemos. Cuando utilizas múltiples repositorios, no tienes dependencias claras. Tienes múltiples versiones de todo y tienes muchas herramientas duplicadas. Cuando haces lo mismo a través de un monorepo, tienes un conjunto de herramientas. Tienes una única versión de dependencias. Y también puedes probar solo lo necesario en cada momento. Suena bastante bien. Entonces, al final del día, ¿por qué usar un monorepo? ¿No es solo la forma en que almacenas tu código? Y no creo que sea así. Creo que en realidad se trata de las personas. No solo se trata del código. Y nuestras personas están organizadas bajo una sola empresa y una sola organización.

5. Implementando un Flujo de Trabajo de Monorepo con NX

Short description:

Podemos usar nx para implementar un flujo de trabajo de monorepo, permitiendo un desarrollo escalable en múltiples equipos. nx nos permite desarrollar como Facebook y proporciona un sistema de construcción inteligente. Admite herramientas modernas y facilita el intercambio de código entre equipos. A través de la generación de código, podemos crear espacios de trabajo sin configuración manual.

Y todos somos un equipo. Aunque podemos tener diferentes responsabilidades dentro de nuestra organización, trabajamos como un equipo y tenemos un objetivo común. Así que veamos cómo podemos usar nx para implementar un flujo de trabajo de monorepo. nx es una herramienta de código abierto que te permite escalar tu desarrollo en múltiples equipos. Esto significa múltiples aplicaciones backend, frontend. Te permite hacerlo todo.

Lo primero que es una característica importante es que te permite desarrollar como Facebook. Entraremos en más detalles sobre lo que esto significa. Lo segundo es que tiene un sistema de construcción inteligente. Así como antes pudimos ver cómo se analizaban y probaban nuestros diferentes proyectos y nx es capaz de hacer eso. También admite el uso de herramientas modernas, como storybook y entraré en más detalles sobre cada una de ellas.

Entonces, para desarrollar como Facebook, como viste con el enfoque moderado, puedes compartir código muy fácilmente entre diferentes equipos. Esto también te brinda una experiencia de desarrollo integral. Tienes todos estos proyectos diferentes bajo un mismo techo y puedes ver cómo diferentes piezas funcionan entre sí y qué está sucediendo en cada parte del repositorio. Puede que no sea importante en todo momento, pero cuando estás trabajando en una tarea específica que involucra otra biblioteca, es maravilloso ver qué está sucediendo allí. Entonces, lo siguiente es cómo puedes mantener la consistencia. A través de la generación de código, podemos crear un espacio de trabajo sin configuración manual. Ejecutamos mpx create-nx-workspace con un conjunto predefinido de React y obtenemos este espacio de trabajo generado con nuestra nueva aplicación para el carrito.

6. Agregando Funcionalidad Compartida y Generando Código

Short description:

Puedes agregar fácilmente funcionalidad compartida sin crear un repositorio separado o configurar un flujo de CI. Con nx generate-lib-shared-button, puedes generar un botón compartido que se puede utilizar en múltiples aplicaciones sin publicarlo en NPM o configurar un CI. También puedes generar un estado Redux con nx generate-redux-cart-directing-into-the-project-of-cart-state, creando una sección de carrito con acciones predefinidas. Además, puedes agregar Next a tu proyecto usando nx generate at rwnellnext app shop, lo que te permite generar una nueva aplicación de tienda en el mismo repositorio que la aplicación de carrito con una configuración mínima.

Puedes agregar funcionalidad compartida muy fácilmente. Antes, tenías que crear un repositorio diferente, tenías que configurar un flujo de CI, publicar en NPM. Pero ahora puedes ejecutar nx generate-lib-shared-button, y ahora tienes un botón compartido que puedes utilizar en múltiples aplicaciones diferentes sin publicar en NPM y sin configurar un CI.

También puedes generar un estado Redux. Todos sabemos que hay mucho código repetitivo y aunque hay cambios en la herramienta Redux, aún hay mucho código que debes escribir para comenzar. Bueno, ahora puedes generarlo usando nx generate-redux-cart-directing-into-the-project-of-cart-state. Esto se genera automáticamente para ti, y puedes ver que podemos crear una sección con un carrito, e incluso tiene algunas acciones predefinidas que puedes cambiar después de generar el código.

También puedes agregar cosas como Next. Usando Yarn at rwnellnext y nx generate at rwnellnext app shop, puedes generar una nueva aplicación de tienda en el mismo repositorio que la aplicación de carrito sin mucha configuración en absoluto. Y Next está completamente configurado y listo para usar.

7. Generación de Código Personalizado con Esquemas de Espacios de Trabajo

Short description:

Si no te gusta lo que NX genera, puedes escribir generación de código personalizado utilizando esquemas de espacios de trabajo. Esto permite a tu organización generar código que implemente tus mejores prácticas deseadas. Es útil para integrarse con diferentes proyectos y garantizar una disposición de código consistente.

¿Qué pasa si no te gusta lo que NX genera? Hay tantas herramientas en el ecosistema que todos amamos y queremos usar, pero es comprensible que es posible que no te guste lo que NX decide generar para ti. Y también hemos tenido esa inspiración, puedes escribir esquemas de espacios de trabajo, que son una generación de código personalizada que se adapta a tu organización, utilizando las mejores prácticas de espacio de trabajo de NX. Y esto realmente permite que tu organización se mantenga consistente al generar el código que implementa las mejores prácticas que deseas tener. Esto es realmente útil cuando deseas integrarte con diferentes proyectos, deseas tener una forma consistente de organizar tu estado, y cosas así. Esta es una de mis características favoritas de NX.

8. Aplicación de Normas y Dependencias con NX

Short description:

NX ayuda a aplicar normas y mejores prácticas al permitirte etiquetar diferentes proyectos y garantizar que las dependencias estén estructuradas correctamente. Proporciona errores de linting para dependencias incorrectas y puede inferir dependencias basadas en las importaciones de código. El NX Step Graph permite visualizar las dependencias, lo cual es crucial para el Intelligent Build System.

Además, NX te ayuda a aplicar normas y mejores prácticas en toda tu organización. Entonces, antes hablábamos de generar código en el formato correcto, pero ¿qué pasa con el código que escribimos? Algo confuso acerca de un Monorepo a veces es que la gente piensa que cualquier biblioteca puede depender de cualquier otra biblioteca, y obtienes una bola de barro que no puedes desenredar y entender. Con NX, puedes etiquetar diferentes proyectos, por lo que el de la izquierda está etiquetado como state y el de la derecha está etiquetado como UI, y todos sabemos que el estado no debe depender de la interfaz de usuario (UI). Debería ser al revés. Entonces, si creamos una dependencia desde el estado hacia la UI, obtenemos un error de linting en nuestro editor. Permíteme hacer zoom para que puedas verlo completo. Un proyecto etiquetado como estado solo puede depender de estado, ¿verdad? No puede depender de estado o de un tipo de UI. NX también es lo suficientemente inteligente como para inferir tus dependencias. Como vimos antes, los proyectos dependen entre sí, y es importante saber cómo están estructuradas esas dependencias. Tomando el código como este, donde importo product UI y también product state desde mi aplicación, NX es capaz de inferir que esta aplicación, la aplicación actual, depende de estas dos bibliotecas sin que tengas que decirlo explícitamente. Luego, una vez que conocemos estas dependencias, también podemos visualizarlas para ti. Ejecutando NX Step Graph, puedes tener una vista interactiva de todas las dependencias dentro de tu proyecto. Entonces, a la derecha, ves que la página de inicio de productos depende de la UI de productos. Estas dependencias también son cruciales para el Intelligent Build System.

9. Mejorando los tiempos de construcción y utilizando herramientas modernas

Short description:

Al utilizar NX, puedes construir solo los proyectos afectados, lo que reduce el tiempo de prueba. La construcción de proyectos en paralelo y la distribución de compilaciones en múltiples agentes mejoran aún más los tiempos de construcción. El almacenamiento en caché de compilaciones anteriores y el uso de una caché remota, como NX Cloud, pueden reducir los tiempos de construcción a solo dos minutos. NX también proporciona herramientas modernas como TypeScript, Jest, Cypress y Storybook, lo que permite un desarrollo y prueba eficientes.

Cuando la gente piensa en monorepos, muchas veces piensan en ejecutar todo, ¿verdad? Y esto es lo que hace Lerna. Y a veces esto se extiende a 60 minutos, o incluso más. Y esto no es muy escalable si queremos hacer un PR y comprobar que funciona en cinco minutos.

Así que veamos algunas formas en las que podemos mejorar esto. NX te permite construir solo los proyectos afectados. Como vimos antes, para un pequeño cambio en este gran monorepo, no necesitamos probar todo. Por lo tanto, podemos extraer las partes del proyecto que son relevantes para nosotros en ese momento y probar solo esas partes, reduciendo nuestros tiempos a la mitad, a unos 25 minutos en este escenario hipotético.

Además, debido a que tenemos diferentes proyectos que se ejecutan de forma independiente, también podemos construirlos en paralelo en la misma máquina. Por lo tanto, podemos ejecutarlos en dos hilos diferentes, y puedes ver que nuestros tiempos, una vez más, se han reducido a la mitad. Luego, también puedes distribuir las compilaciones en múltiples agentes. No solo puedes paralelizarlos en la misma máquina, sino que también puedes distribuirlos. Por lo tanto, si tengo cinco trabajadores diferentes, ahora puedo probar estos cinco proyectos diferentes en nodos diferentes en mi CI. Y como puedes ver aquí, la barra roja allí todavía es bastante larga. Para acortarla, también podemos almacenar en caché las compilaciones anteriores. Si ya hemos realizado esta compilación antes, aunque mi cambio realmente la afecte, puede darse cuenta de que ya he realizado esta compilación antes. No lo hagamos de nuevo. Y puede obtener eso de una caché, reduciendo los tiempos a dos minutos.

Ahora, la mejor manera de hacer esto es a través de una caché remota, que puedes agregar agregando NX Cloud, que es nuestro complemento pago para NX. Pero NX es open-source, nuevamente, por lo que no necesariamente lo necesitas. Seis minutos es un tiempo más que favorable en comparación con los 60 minutos. Pero NX Cloud te permite no construir lo mismo dos veces.

Entonces, lo último es poder utilizar herramientas modernas. NX viene configurado de forma predeterminada con TypeScript, Jest, Cypress y Storybook. Estoy seguro de que todos están familiarizados con Jest, e incluso pueden tener sus propias opiniones sobre TypeScript, pero también puedes usar JavaScript dentro de tu repositorio con NX. Dos cosas con las que es posible que no estés familiarizado son Cypress, que es una experiencia de pruebas de extremo a extremo, por lo que no solo te permite escribir tus pruebas, sino que también te brinda una interfaz donde puedes viajar en el tiempo a través de esas pruebas y asegurarte de que no estés teniendo problemas al ejecutar tus pruebas de extremo a extremo. Storybook te permite desarrollar tus componentes de forma aislada, de la manera en que nos gusta pensar en ello durante nuestros desarrollos de React, y esto es realmente importante para poder ver cómo se ven estos componentes de la interfaz de usuario cuando están aislados de la aplicación en la que se desarrollan. También puedes instalar todos estos complementos por separado. Si no quieres Storybook, no tienes que instalar Storybook. Puedes instalar solo React y Next si quieres usarlo. También puedes instalar Node.js, Express y HTML si lo deseas, e incluso puedes instalar complementos de Angular y Nest.js.

10. Using Plugins and a Live Demo

Short description:

Todo esto es a la carta, así que eliges lo que quieres. También tenemos complementos de la comunidad para herramientas favoritas. Puedes crear tu propio complemento usando mpx create-nx-plugin. Vamos a hacer una demostración en vivo. En nuestra aplicación de coche, se importa la funcionalidad del encabezado compartido. Los cambios se pueden realizar y probar fácilmente sin tener que ir a un repositorio diferente. La aplicación se puede verificar y actualizar con los últimos cambios.

Todo esto es a la carta, así que eliges lo que quieres y no tienes nada superfluo que no estés usando. También tenemos complementos de la comunidad. Tenemos la capacidad de que las personas de la comunidad creen complementos para sus herramientas favoritas, como migrar de Karma a Jest o implementar sin servidor. En nuestro muro, no podemos admitir todas las tecnologías existentes en cada proyecto de la comunidad, pero la comunidad ha hecho un gran trabajo creando complementos para que otras personas los usen. Y tú también puedes crear tu propio complemento. Si ejecutas mpx create-nx-plugin, creará un espacio de trabajo diferente para ti que sea adecuado para el desarrollo de complementos.

Así que con eso fuera del camino, vamos a hacer una demostración en vivo. Voy a entrar en un espacio de trabajo regular aquí. Ya está configurado, así que no te mostraré todos los pasos de generación de código, aunque vimos que era bastante fácil. La mayoría de este código aquí se configuró en una sola página. La mayoría de este código aquí se configuró mediante la generación de código, pero quiero echar un vistazo a nuestra aplicación de coche. En nuestra aplicación de coche, en nuestro componente principal, vemos que este archivo aquí importa desde un proyecto diferente llamado encabezado compartido. Así que como desarrolladores, sabemos que, obviamente, la aplicación de coche depende de la funcionalidad en el encabezado compartido. Entonces, cuando tenemos nuestro encabezado de ejemplo de Nx aquí, la funcionalidad no se encuentra dentro de este directorio aquí. En realidad, se encuentra en un directorio separado. Así que sigamos esa importación. Y tenemos nuestros elementos de encabezado. Siendo estos nuestros elementos de encabezado, podemos ver que así es como funciona sin tener que ir a un repositorio diferente. Si quisiera cambiar la forma en que funciona, puedo agregar un bloque de consola aquí. Hola, React Summit. Guardar esto. Ver que mis cambios están en Git. Y esto es genial. Puedo hacer un PR. Puedo verificar mi aplicación de coche aquí ejecutando current start cart. Y ahora puedo ver mi aplicación en ejecución con nuestros últimos cambios. Así que si abro esto. Dame un segundo. Vale, así que podemos ver que mi registro de consola aparece aquí. Tenemos el encabezado y nuestra aplicación de coche sigue viéndose bien.

QnA

Code Testing and Dependency Visualization

Short description:

NX puede mostrar las dependencias en tu código y determinar automáticamente qué pruebas ejecutar. La función de gráfico de profundidad te permite visualizar las dependencias del proyecto y centrarte en áreas específicas. Esto elimina la necesidad de realizar un seguimiento manual de las dependencias, que rápidamente pueden quedar obsoletas. Puedes encontrar el repositorio de ejemplo en narwhal/NX examples, que muestra el uso de múltiples frameworks en el mismo repositorio. Sígueme en Twitter en Verzopandas y visita nx.dev para obtener más información. Ahora, pasemos a la sesión de preguntas y respuestas.

Volviendo al código, ahora que hemos realizado estos cambios, no sabemos con certeza hasta que ejecutemos nuestras pruebas si la aplicación de coche se ve bien en CI. Podría probar mi encabezado compartido y luego, después de eso, puedo probar mi carrito. Así que puedo dejar que se ejecuten. Voy a confiar en que ambos funcionan, pero es un poco tedioso tener estas dependencias en mente todo el tiempo.

NX puede mostrarte esto. Si ejecuto 'effective test', revisará mis cambios en Git y se dará cuenta de que necesito verificar mi carrito y también necesito probar mi encabezado. Así que automáticamente lo sabe y no necesitas decírselo. Esto es genial para usarlo en CI, donde tienes un número arbitrario de cambios en múltiples proyectos y solo quieres probar lo que es necesario.

Y como te mencioné antes, puedes ver el gráfico de profundidad. Al ejecutar 'NX depth graph', se abrirá el gráfico de profundidad interactivo en un navegador. Puedes ver muchos proyectos aquí y todos dependen entre sí. Pero digamos que solo estoy trabajando en mi página de carrito en este momento. Puedo enfocarme en mi página de carrito y ver que estas son las únicas dependencias que tiene mi página de carrito separadas del resto. Y si no me importa realmente mi fecha de producto aquí, puedo excluir eso de la vista y ver una imagen aún más clara. También puedo agrupar las cosas por carpeta para ver dónde se encuentran las cosas dentro del repositorio y cosas así. Esto es realmente útil porque en el pasado, un arquitecto tendría que ir a una página de Wikipedia y actualizar con lo que cree que depende de qué y rápidamente se vuelve obsoleto.

Eso es todo el tiempo que tengo para mostrarte cosas en el código por ahora. Así que continuemos con la presentación. Puedes encontrar el repositorio del que te mostré ejemplos en narwhal/NX examples. Por favor, échale un vistazo, tiene una aplicación de coche escrita en React y las aplicaciones de producto están escritas en Angular. Así que puedes ver cómo se pueden usar múltiples frameworks en el mismo repositorio, pero aún así compartir código entre los dos sin problemas. Eso es todo por mi charla. Puedes seguirme en Twitter en Verzopandas y también asegúrate de visitar nx.dev, nx.app es para NX Cloud y síguenos en Twitter en nx DevTools. Muy bien. Muchas gracias y me encantaría responder tus preguntas ahora.

Leadership, Code Dependency, and Deployment

Short description:

Gracias, Jason y Gene, por la excelente charla sobre el desarrollo escalable de React. Un monorepo puede mejorar enormemente la colaboración y reducir la fricción entre equipos. Empresas como Facebook han utilizado con éxito monorepos para implementar código rápidamente. Con NX, puedes migrar fácilmente si es necesario sin cambiar tu base de código. NX admite la implementación en diferentes entornos, y los monorepos pueden funcionar bien con micro frontends, simplificando la gestión y reduciendo el trabajo repetitivo.

Eso estuvo genial. Muchas gracias, Jason, Gene, por esa charla. Fue excepcional. Y me recuerda, cuando trabajaba en IBM, teníamos muchos microservicios y nos llevó mucho tiempo implementar esas cosas y algo como Nx realmente nos hubiera sido útil.

Entonces, demos la bienvenida de nuevo a JJ. Gracias por venir. Tenemos algunas preguntas interesantes de la audiencia. Así que voy a empezar de inmediato.

La primera es realmente interesante para mí porque creo que es casi la parte más importante del desarrollo de software de la que no siempre hablamos, que es cómo convencer al liderazgo y a otras personas del equipo de hacer un cambio como este. Y más específicamente, ¿cómo convencer al liderazgo de que un monorepo no es un acoplamiento fuerte de código? Sí, creo que desde el punto de vista del liderazgo se verá mucha colaboración entre múltiples equipos. Y hay muchas dependencias entre diferentes equipos que crean fricción cuando no trabajan bien juntos, y un monorepo cambia drásticamente eso. Empresas como Facebook pueden colaborar entre múltiples equipos diferentes. Y de hecho, tenemos un case study con T-Mobile sobre cómo pudieron usar un monorepo e implementar su nueva tienda rápidamente, relativamente hablando. Y en cuanto al acoplamiento fuerte, tienes mucho código pero puedes hacer múltiples copias de ese código como Kent mencionó en su charla y cosas así. Así que aún puedes tener diferentes relaciones entre tu código y no necesariamente estar fuertemente acoplados.

De acuerdo. Otra gran pregunta aquí es, si comienzas a usar NX, ¿qué tan dependiente se vuelve la base de código de NX? Si decides más tarde que quieres dejar de usarlo, ¿es algo de lo que puedes migrar fácilmente? Sí, NX es una herramienta de desarrollo, ¿verdad? Así que no tiene nada que ver con tu código de producción. Y las cosas que están bajo NX, aunque son muy inteligentes y las tenemos disponibles para todos, puedes hacerlo tú mismo, ¿verdad? O puedes usar otra herramienta que también funcione con esto. Entonces, empresas como Facebook no usan NX internamente, pero tienen sus propias herramientas. Creo que se llama Pants o Buck, una de ellas, ¿verdad? Y hace cosas muy similares, pero es mucho más difícil de configurar. Pero sí, si algún día decides que NX no funciona para ti y necesitas algo más, entonces puedes dejar de usarlo. No cambia la forma en que escribes tu código, solo trabaja en torno a él. Así que sí.

A ver. ¿NX admite la implementación en diferentes entornos, como si quisieras implementar en Heroku? Sí, NX admite... Cada proyecto puede implementarse de manera diferente según lo que necesiten. De hecho, hay un community plugin para Netlify y muchos otros servicios como Firebase. Así que es a nivel de proyecto. Si quieres implementar una API de esta manera, quieres implementar un front-end de otra manera, otro front-end de otra manera, tienes libertad total. Una pregunta que vi y que me gustó mucho es cómo podrían trabajar juntos los monorepos y los micro frontends. Sí, creo que hay una idea equivocada de que son mutuamente excluyentes y la gente habla de dividir su monolito en diferentes repositorios, pero puedes tener todos estos diferentes, los micro frontends son proyectos diferentes que este monorepo. Y de hecho, creo que el monorepo facilita la gestión de los micro frontends, ¿verdad? Porque cuando divides todo en frontends separados, cuando te asignan la tarea de cambiar como el encabezado universal en todos ellos, solo tienes este enorme trabajo repartido en diferentes repositorios y haciendo el mismo cambio varias veces.

Trabajando con Monorepo y Flujo de Trabajo

Short description:

Con un monorepo, puedes realizar cambios y actualizaciones en todos los micro frontends a la vez, eliminando el desafío de trabajar en múltiples frontends. NX te permite mover partes publicables a NX y ver las relaciones entre ellas. También tiene la inteligencia para ejecutar solo una parte de tus proyectos cuando sea necesario. Los conflictos de fusión son menos comunes en un monorepo, ya que los desarrolladores generalmente trabajan en partes diferentes. Para los cambios que afectan a todo el monorepo, puede haber conflictos de fusión, pero resolverlos una vez sigue siendo más eficiente que lidiar con conflictos en diferentes equipos. Se recomienda un flujo de trabajo de desarrollo basado en tronco para equipos grandes que trabajan en un solo repositorio.

Y con el monorepo, puedes hacer el cambio, hacer todas las correcciones de una vez y se actualizan todos los micro frontends, ¿verdad? Así que en realidad te has deshecho de ese gran obstáculo de trabajar en estos micro frontends al ponerlos en el mismo lugar. Y tengo una publicación en el blog al respecto. Así que puedes ver como los micro frontends de React son una combinación perfecta con los monorepos.

De acuerdo, sí. Así que una pregunta que veo aquí, la reformularé un poco para no señalar a nadie, pero si tienes un equipo donde el patrón ha sido crear un nuevo repositorio para cada cosa pequeña, ¿cuál es tu recomendación para ayudar a los equipos a trabajar dentro del marco de NX Monorepo cuando ese ha sido el patrón anterior de dividir todo en pequeñas bases de código? Sí, y supongo que a medida que divides el código en pequeñas bases de código, también las publicas en un registro en algún lugar para que las personas puedan descargarlas. Creo que lo primero que haría es mover las partes publicables a NX y luego tener los diferentes proyectos dentro de NX y puedes ver las relaciones entre ellos, pero luego puedes publicarlos de nuevo, ya sabes, en artifactory, o cualquier otro registro, y luego puedes comenzar a incorporarlos desde nodos más altos de tu gráfico de dependencias.

Mm-hmm. Entonces, una pregunta que tengo es ¿cuál es la diferencia entre algo como NX y otras herramientas de gestión de monorepos como Lerna? ¿Son lo mismo o resuelven problemas diferentes? Sí, Lerna es muy popular y es realmente bueno, creo, para la gestión de paquetes. Entonces, NX tiene muchos paquetes diferentes que gestionamos y no usamos Lerna, pero sería bueno tener algo que simplemente ejecute todo, y eso es lo que hace Lerna. Te permite tener proyectos separados, pero te permite ejecutar compilaciones en todos ellos, probarlos a todos. Pero al final de mi charla estaba hablando de cómo, ya sabes, ejecutar todo llevará mucho tiempo una vez que llegues a la escala de cinco o seis equipos diferentes. Entonces, cuando hablas de organizaciones como Facebook, ejecutar todas las pruebas lleva mucho tiempo. Así que NX tiene la inteligencia, junto con eso, para poder ejecutar solo una parte de tus proyectos cuando sea necesario para verificar que el cambio sea seguro para la producción.

Entendido. Entonces, eso se relaciona con otra pregunta aquí, que es cómo se admite a los equipos grandes que trabajan en un solo repositorio si se necesita algo como una cola de fusión. Puede que no esté tan familiarizado con el término de cola de fusión, pero tal vez sea como, ya sabes, muchas personas trabajando en el mismo monorepo, podrías imaginar muchos conflictos de fusión, ¿verdad? Creo que también es una idea equivocada porque los conflictos de fusión solo ocurren cuando dos personas trabajan en lo mismo. Y no es exactamente como, ya sabes, mil personas trabajando en el mismo fragmento de código, ¿verdad? Todos están trabajando en su pequeña parte del monorepo. Así que muchas veces no tendrás conflictos de fusión, ¿verdad?, porque estás trabajando en algo completamente diferente a otras personas. Lo único es cuando estás trabajando en un cambio que afecta a todo el monorepo, digamos, como cambiar algo muy importante, entonces sí, habrá conflictos de fusión cuando las personas fusionen su código. Pero bueno, solo tendrás que hacerlo una vez en lugar de hacerlo 50 veces diferentes en todos esos equipos diferentes. Entonces, al final del día, sigue siendo más eficiente desde el punto de vista del flujo de trabajo, ¿verdad?, y sí, la única otra recomendación que tengo es que tal vez necesites esto, ya sabes, necesito este cambio, déjame simplemente forzarlo sin obtener todas mis aprobaciones o como, hay un equipo separado que maneja ese tipo de cambio. Así es como recomendaría hacerlo. No estoy seguro si entendí correctamente la cola de fusión. Entonces, la pregunta ha sido reformulada para hablar sobre una cola de implementación. Y bueno, voy a hablar sobre mi propia experiencia porque sé con certeza lo que estoy preguntando, solo para asegurarme. Y lo que he visto es que en muchas empresas, cuando estás listo para implementar algo en particular, digamos que el frontend de la aplicación está a punto de implementar algo. Puede haber múltiples ramas en marcha, pero bloquearán la implementación durante un período de tiempo para asegurarse de que el código se fusione y se implemente correctamente. El flujo de trabajo que usamos ahora no funcionaría en un monorepo porque estaríamos bloqueando a toda la empresa. La mayoría de ese código no se ve afectado por la implementación del frontend. Entonces, ¿cómo funciona un flujo de trabajo así, donde necesito decir, nadie puede fusionar en la interfaz de usuario durante este período de tiempo, cómo funcionaría eso? Sí, el flujo de trabajo de desarrollo que funciona muy bien con monorepos es un desarrollo basado en tronco. Eso significa que todos desarrollan en función de la rama principal o de desarrollo, pero todos los commits van allí.

Lanzamiento de aplicaciones desde Monorepo

Short description:

Puedes lanzar una aplicación separada sin lanzar todo el monorepo a la vez. Corta una rama de lanzamiento desde master, despliégala en un entorno de QA o staging, ejecuta pruebas y despliégala en base a esa rama. Mientras tanto, master continúa y otros equipos pueden cortar sus propias ramas para el despliegue. El desarrollo basado en tronco funciona de la mano con los monorepos.

Cuando llega el momento de hacer lanzamientos, y como mencioné, puedes lanzar una aplicación separada por sí misma. No tienes que lanzar todo el monorepo a la vez. Entonces, lo que puedes hacer es cortar una rama de lanzamiento basada en master, ¿verdad? Y digamos que es un lanzamiento para el 17 de abril. No lances en un viernes, pero digamos que has cortado esta rama de lanzamiento, la despliegas en un entorno de QA, un entorno de staging, lo que sea, ¿verdad? Realizas esas pruebas, y luego despliegas en base a esa rama, ¿verdad? Mientras tanto, master sigue avanzando, pero no tienes que preocuparte, ¿verdad? Todos siguen trabajando en ello, ¿verdad? Y cosas así. Y luego, cuando otro equipo quiera hacer su propio despliegue, pueden cortar una rama desde master, ¿verdad? Y luego usarla para el lanzamiento. Así que recomiendo investigar el desarrollo basado en tronco y lo que eso significa. Funciona de la mano con los monorepos. Es una gran pregunta. Genial. Y eso es todo el tiempo que tenemos. JJ, muchas gracias por la charla. Gracias por acompañarnos y responder preguntas. Y recuerden, si tienen un boleto pagado, JJ está a punto de ir a una sala especial donde pueden tener tiempo con él. Así que asegúrense de revisar los detalles de su boleto y unirse si tienen preguntas adicionales. ...

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 2022React Advanced Conference 2022
25 min
A Guide to React Rendering Behavior
Top Content
React is a library for "rendering" UI from components, but many users find themselves confused about how React rendering actually works. What do terms like "rendering", "reconciliation", "Fibers", and "committing" actually mean? When do renders happen? How does Context affect rendering, and how do libraries like Redux cause updates? In this talk, we'll clear up the confusion and provide a solid foundation for understanding when, why, and how React renders. We'll look at: - What "rendering" actually is - How React queues renders and the standard rendering behavior - How keys and component types are used in rendering - Techniques for optimizing render performance - How context usage affects rendering behavior| - How external libraries tie into React rendering
React Summit Remote Edition 2021React Summit Remote Edition 2021
33 min
Building Better Websites with Remix
Top Content
Remix is a new web framework from the creators of React Router that helps you build better, faster websites through a solid understanding of web fundamentals. Remix takes care of the heavy lifting like server rendering, code splitting, prefetching, and navigation and leaves you with the fun part: building something awesome!
React Advanced Conference 2023React Advanced Conference 2023
33 min
React Compiler - Understanding Idiomatic React (React Forget)
React provides a contract to developers- uphold certain rules, and React can efficiently and correctly update the UI. In this talk we'll explore these rules in depth, understanding the reasoning behind them and how they unlock new directions such as automatic memoization. 
React Advanced Conference 2022React Advanced Conference 2022
30 min
Using useEffect Effectively
Top Content
Can useEffect affect your codebase negatively? From fetching data to fighting with imperative APIs, side effects are one of the biggest sources of frustration in web app development. And let’s be honest, putting everything in useEffect hooks doesn’t help much. In this talk, we'll demystify the useEffect hook and get a better understanding of when (and when not) to use it, as well as discover how declarative effects can make effect management more maintainable in even the most complex React apps.
React Summit 2022React Summit 2022
20 min
Routing in React 18 and Beyond
Top Content
Concurrent React and Server Components are changing the way we think about routing, rendering, and fetching in web applications. Next.js recently shared part of its vision to help developers adopt these new React features and take advantage of the benefits they unlock.In this talk, we’ll explore the past, present and future of routing in front-end applications and discuss how new features in React and Next.js can help us architect more performant and feature-rich applications.
React Advanced Conference 2021React Advanced Conference 2021
27 min
(Easier) Interactive Data Visualization in React
Top Content
If you’re building a dashboard, analytics platform, or any web app where you need to give your users insight into their data, you need beautiful, custom, interactive data visualizations in your React app. But building visualizations hand with a low-level library like D3 can be a huge headache, involving lots of wheel-reinventing. In this talk, we’ll see how data viz development can get so much easier thanks to tools like Plot, a high-level dataviz library for quick & easy charting, and Observable, a reactive dataviz prototyping environment, both from the creator of D3. Through live coding examples we’ll explore how React refs let us delegate DOM manipulation for our data visualizations, and how Observable’s embedding functionality lets us easily repurpose community-built visualizations for our own data & use cases. By the end of this talk we’ll know how to get a beautiful, customized, interactive data visualization into our apps with a fraction of the time & effort!

Workshops on related topic

React Summit 2023React Summit 2023
170 min
React Performance Debugging Masterclass
Featured WorkshopFree
Ivan’s first attempts at performance debugging were chaotic. He would see a slow interaction, try a random optimization, see that it didn't help, and keep trying other optimizations until he found the right one (or gave up).
Back then, Ivan didn’t know how to use performance devtools well. He would do a recording in Chrome DevTools or React Profiler, poke around it, try clicking random things, and then close it in frustration a few minutes later. Now, Ivan knows exactly where and what to look for. And in this workshop, Ivan will teach you that too.
Here’s how this is going to work. We’ll take a slow app → debug it (using tools like Chrome DevTools, React Profiler, and why-did-you-render) → pinpoint the bottleneck → and then repeat, several times more. We won’t talk about the solutions (in 90% of the cases, it’s just the ol’ regular useMemo() or memo()). But we’ll talk about everything that comes before – and learn how to analyze any React performance problem, step by step.
(Note: This workshop is best suited for engineers who are already familiar with how useMemo() and memo() work – but want to get better at using the performance tools around React. Also, we’ll be covering interaction performance, not load speed, so you won’t hear a word about Lighthouse 🤐)
React Advanced Conference 2021React Advanced Conference 2021
132 min
Concurrent Rendering Adventures in React 18
Top Content
Featured WorkshopFree
With the release of React 18 we finally get the long awaited concurrent rendering. But how is that going to affect your application? What are the benefits of concurrent rendering in React? What do you need to do to switch to concurrent rendering when you upgrade to React 18? And what if you don’t want or can’t use concurrent rendering yet?

There are some behavior changes you need to be aware of! In this workshop we will cover all of those subjects and more.

Join me with your laptop in this interactive workshop. You will see how easy it is to switch to concurrent rendering in your React application. You will learn all about concurrent rendering, SuspenseList, the startTransition API and more.
React Summit Remote Edition 2021React Summit Remote Edition 2021
177 min
React Hooks Tips Only the Pros Know
Top Content
Featured Workshop
The addition of the hooks API to React was quite a major change. Before hooks most components had to be class based. Now, with hooks, these are often much simpler functional components. Hooks can be really simple to use. Almost deceptively simple. Because there are still plenty of ways you can mess up with hooks. And it often turns out there are many ways where you can improve your components a better understanding of how each React hook can be used.You will learn all about the pros and cons of the various hooks. You will learn when to use useState() versus useReducer(). We will look at using useContext() efficiently. You will see when to use useLayoutEffect() and when useEffect() is better.
React Advanced Conference 2021React Advanced Conference 2021
174 min
React, TypeScript, and TDD
Top Content
Featured WorkshopFree
ReactJS is wildly popular and thus wildly supported. TypeScript is increasingly popular, and thus increasingly supported.

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

React+TypeScript, with JetBrains IDEs? That three-part combination is the topic of this series. We'll show a little about a lot. Meaning, the key steps to getting productive, in the IDE, for React projects using TypeScript. Along the way we'll show test-driven development and emphasize tips-and-tricks in the IDE.
React Advanced Conference 2021React Advanced Conference 2021
145 min
Web3 Workshop - Building Your First Dapp
Top Content
Featured WorkshopFree
In this workshop, you'll learn how to build your first full stack dapp on the Ethereum blockchain, reading and writing data to the network, and connecting a front end application to the contract you've deployed. By the end of the workshop, you'll understand how to set up a full stack development environment, run a local node, and interact with any smart contract using React, HardHat, and Ethers.js.
React Summit 2023React Summit 2023
151 min
Designing Effective Tests With React Testing Library
Featured Workshop
React Testing Library is a great framework for React component tests because there are a lot of questions it answers for you, so you don’t need to worry about those questions. But that doesn’t mean testing is easy. There are still a lot of questions you have to figure out for yourself: How many component tests should you write vs end-to-end tests or lower-level unit tests? How can you test a certain line of code that is tricky to test? And what in the world are you supposed to do about that persistent act() warning?
In this three-hour workshop we’ll introduce React Testing Library along with a mental model for how to think about designing your component tests. This mental model will help you see how to test each bit of logic, whether or not to mock dependencies, and will help improve the design of your components. You’ll walk away with the tools, techniques, and principles you need to implement low-cost, high-value component tests.
Table of contents- The different kinds of React application tests, and where component tests fit in- A mental model for thinking about the inputs and outputs of the components you test- Options for selecting DOM elements to verify and interact with them- The value of mocks and why they shouldn’t be avoided- The challenges with asynchrony in RTL tests and how to handle them
Prerequisites- Familiarity with building applications with React- Basic experience writing automated tests with Jest or another unit testing framework- You do not need any experience with React Testing Library- Machine setup: Node LTS, Yarn