React a gran escala con Nx

Muy bien, todos. Bienvenidos a React a gran escala con NX. Sí, ¡vamos! Mi nombre es Isaac Mann. Soy arquitecto en Narwhal. He estado aquí durante tres años y medio. Y, Zach, ¿quieres presentarte?

Claro, mientras encuentro el botón de silencio. Soy Zach Derose. Llevo casi cuatro años en Narwhal. Soy ingeniero senior y gerente de ingeniería, al igual que Isaac, y estoy emocionado de compartir este conocimiento de NX con todos ustedes. Así que, sí. Sí. Zach y yo nos unimos con una diferencia de dos semanas. Así que puedes ver cómo Zach es el optimista. Así que lleva casi cuatro años. Y yo digo, bueno, más de tres años. Así que, vaso medio lleno, vaso medio vacío. Sí, supongo. Lo siento, no escuché tu presentación porque estaba escribiendo en el chat. Pero, sí. Eso es gracioso.

Sí, hoy te daremos una introducción a NX a través de un masterclass que normalmente tenemos configurado para un masterclass de dos días. Vamos a cubrir el primer día en tres horas. Normalmente toma alrededor de seis horas, pero vamos a intentar cubrirlo lo mejor que podamos en tres horas. Básicamente, eso significa que reduciremos el tiempo que te daremos para hacer las cosas por tu cuenta. Voy a guiarlos a través de los laboratorios y te daré tiempo para hacer preguntas. Pero no vamos a hacer pausas de 10 minutos en cada laboratorio para que hagas todo por tu cuenta. Pero el repositorio está enlazado en el chat. Así que si sientes que voy demasiado rápido, está ahí y puedes hacerlo a tu propio ritmo más tarde. Algunas notas solo para, supongo, notas de procedimiento. Queremos asegurarnos de que este sea un entorno amigable donde todos se sientan bienvenidos e incluidos. Esto incluye cualquier elección de vida que las personas hagan y cualquier elección técnica que las personas hagan. Así que no avergonzar a las personas por lo que elijan hacer con su vida y no avergonzar a las personas por las tecnologías que utilizan en el trabajo. Así es. Y no avergonzaremos a las personas por usar IE, aunque se esté eliminando gradualmente, creo, esta semana, ¿mañana? No sé. Hay una gran celebración sucediendo. Sí, hoy. Muy bien. ¿Algo más que me esté perdiendo, Zach, antes de comenzar?

No, solo un recordatorio, sin embargo, para cualquier persona nueva, lo he estado diciendo mucho, pero estaré en el chat. Así que usemos el chat de Zoom si tienen alguna pregunta mientras avanzamos. Responderé lo que pueda. Y si es apropiado, interrumpiremos a Isaac para repasar algunas cosas mientras comparte su pantalla. Así que sí, genial. Muy bien. Voy a compartir mi pantalla y compartir mi pantalla completa aquí. Y vamos a pasar por algunas diapositivas. Muy bien, esto es React a gran escala con NX Monorepos. Y una cosa con la que deberíamos comenzar es definir qué es un monorepo y por qué querrías usar un monorepo. Un monorepo es un repositorio, generalmente un repositorio Git, donde tienes múltiples aplicaciones en el mismo repositorio. Y el beneficio de codificar de esa manera es que obtienes cambios atómicos, compartes código más fácilmente y puedes obtener un conjunto único de dependencias. Permíteme retroceder un poco. Hay dos tipos de monorepos en los que puedes meterte. Está el estilo de monorepo de Google, por falta de una mejor palabra, donde hay muchas tooling y muchas cosas para ayudarte a compartir código mejor. Y luego está el estilo de aprendiz o muy ligero, menos tooling. Y hablaremos de eso un poco más adelante con el, creo que lo llamamos co-ubicación de código a veces. Pero NX puede ayudar con ambos. Pero durante este masterclass, vamos a hablar del estilo de Google, que tiene un conjunto único de dependencias, un archivo package JSON en la raíz. Mientras que el estilo de aprendiz es que tienes muchos package JSON con diferentes dependencias para cada aplicación en tu repositorio. Así que nos vamos a enfocar en ese estilo de Google para este masterclass. Pero al final, podríamos hacer una demostración de cómo se vería NX en el estilo de aprendiz de monorepo. Tenemos estas tres cosas que un monorepo te brinda, cambios atómicos, código compartido y un conjunto único de dependencias. Ahora veamos qué significa cada una de estas cosas. Los cambios atómicos son, digamos que tienes una aplicación y una biblioteca en tu repositorio. En realidad, en este caso, las tenemos en dos repositorios separados. Entonces tienes la aplicación en una biblioteca de UI. Si los tienes en dos repositorios separados, entonces digamos que haces un cambio en tu biblioteca y rompe algún comportamiento en tu aplicación. Entonces el autor de la biblioteca hace un cambio, lo publica. El desarrollador de la aplicación en algún momento posterior actualiza a la última versión de la biblioteca. Y se dan cuenta, oye, esto está roto. No podemos usar esta próxima versión de la biblioteca. Así que le dicen al desarrollador de la biblioteca, OK, presentan un error. Necesitas arreglar esto. Y luego, más tarde, el desarrollador de la biblioteca vuelve y dice, OK, tengo que arreglar eso. Hace el cambio. Publica una nueva versión. Y luego, más tarde, el desarrollador de la aplicación actualiza a la próxima versión de la biblioteca y dice, OK, finalmente está arreglado. Así que ese es el largo tiempo de ciclo si los tienes en dos repositorios separados. Si estuvieran en un solo repositorio, entonces el desarrollador de la biblioteca, cuando hace el cambio, podría ejecutar las pruebas para toda la aplicación, todo el repositorio, y decir, oh, espera, este cambio que estoy a punto de hacer, rompe esta otra aplicación, así que lo voy a arreglar ahora mismo. Así que tienes un tiempo de ciclo de 45 minutos en lugar de una semana. Ese es el beneficio de un cambio atómico. Haces un cambio y puedes ver los efectos de inmediato en toda la aplicación incluso antes de hacer un commit. El segundo punto es que es más fácil compartir código. Digamos que tienes una función llamada username is valid, y esta lógica se utiliza en muchas aplicaciones diferentes, si tienes un monorepo, compartir ese código es tan fácil como exportar una función e importarla en otro lugar. Y cada vez que cambias esa lógica, se aplica de inmediato en todo tu repositorio. Mientras que si tienes repositorios separados, tienes que versionar las cosas y republicarlas, y tienes todo ese tiempo de ciclo, ese retraso en tu proceso de desarrollo, como dije con los commits atómicos. El tercer beneficio es tener un conjunto único de dependencias. A menudo, si tienes múltiples aplicaciones, siempre habrá algunas aplicaciones en las que estás desarrollando todo el tiempo que estarán en las últimas versiones de las cosas. Y habrá algunas aplicaciones que solo tocas ocasionalmente y siempre se quedan atrás. Y actualizarlas y avanzar es un dolor porque inevitablemente, se quedan seis versiones atrás y tienes que recordar todos los problemas que tuviste que resolver durante el último año cuando estabas actualizando cosas, tienes que volver y revivirlos todos una y otra vez mientras actualizas esta aplicación antigua. Mientras que si mantienes todo en la misma versión, solo haces ese cambio una vez y lo haces en toda tu aplicación.

Dices, bien, cada vez que veo este patrón de código, hago esta corrección y lo haces una vez y ya está. En lugar de tener que hacerlo ahora y luego dentro de dos meses y luego dentro de seis meses para todas las diferentes aplicaciones que estás viendo. La otra cosa que ayuda un conjunto único de dependencias es si estás haciendo un enfoque de micro-fundición, debes tener las cosas en la misma versión, de lo contrario, obtendrás errores extraños con una biblioteca de React 16 que intenta inyectarse en una aplicación de React 17 y las cosas están confundidas acerca de qué es un singleton de una determinada instancia o lo que sea. Entonces, tener un conjunto único de dependencias simplemente elimina toda esa clase de problemas.

Bien, la co-ubicación de código es lo que harías si simplemente colocaras múltiples aplicaciones en el mismo repositorio sin ninguna herramienta alrededor. Simplemente lo colocas y dices, será mejor, podremos compartir nuestro código y será agradable. Pero aquí están los problemas con eso. El tiempo que lleva ejecutar las pruebas crecerá exponencialmente. Tienes problemas para tener límites de código y mantener las cosas contenidas y no tener código espagueti. Y luego tendrás herramientas inconsistentes cuando intentes administrar tu base de código. Por lo tanto, se ejecutan pruebas innecesarias.

Entonces, digamos que tienes una página de inicio que depende de una biblioteca de UI. Si cambiaras la página de inicio, solo necesitarías ejecutar la prueba para la página de inicio. No necesitas ejecutar la prueba para la biblioteca de UI porque no hay forma de que un cambio en la página de inicio pueda romper la biblioteca de UI porque así funciona la dependencia. Pero si no tienes las herramientas que entienden eso, no sabrás qué pruebas debes ejecutar. Entonces, terminas ejecutando las pruebas de todo cada vez que haces algún cambio. Y eso hace que el tiempo que lleva tu CI crezca exponencialmente con la cantidad de cosas que agregas porque cada aplicación que agregas agrega más pruebas que debes ejecutar sin importar dónde se realice ese cambio. Incluso si estás haciendo cambios en una aplicación que no tiene dependencia de la otra, debes ejecutar la prueba de todo solo para asegurarte de no haber roto algo por accidente.

Y obviamente, este es un ejemplo muy pequeño. Puedes darte cuenta solo con mirarlo si necesitas ejecutar pruebas para algo o no. Pero tu gráfico de dependencias se verá más o menos así, este es incluso un repositorio muy pequeño. En cualquier empresa de tamaño moderado, tendrás cientos de nodos en este gráfico una vez que comiences a trabajar en cosas. En ese punto, no puedes saber como persona solo entendiendo el código qué pruebas realmente necesitan ejecutarse, debes tener algunas herramientas que lo hagan por ti. Entonces, debes saber que cuando cambias la biblioteca de la página del carrito, debes saber que la herramienta puede decirte que debes probar la aplicación del carrito y luego la aplicación de extremo a extremo del carrito porque son las cosas que dependen de ella. Muy bien. Quieres tener límites de código. Entonces, digamos que tienes algo en tu biblioteca que solo quieres usar internamente en esa biblioteca o sabes que va a cambiar y no quieres que otras personas en otras partes del código lo usen. Entonces, podrías hacer cosas como, sé que React hace esto a veces, tienen inestable o prefijan los nombres de las cosas con mensajes de advertencia para las personas para decir, oye, no uses esto en realidad, es tu culpa si usas esto, esto va a cambiar, va a romper tu código. Y solo para evitar que las personas dependan de cosas que no están destinadas al consumo público. Mientras que si tienes herramientas que te impiden hacer estas importaciones profundas, puedes detener este problema antes de que ocurra.

Muy bien, la otra cosa es la herramienta inconsistente. Si tienes muchas aplicaciones en tu repositorio, obtienes los scripts de NPM que se inflan. Y el formato de esos scripts de NPM se basa en el capricho del desarrollador en el momento en que lo escribió. Porque siempre van a tener alguna bandera aleatoria que nadie conoce o espera. Y ni siquiera sabes cómo hacer cosas diferentes. Entonces, una aplicación podría ser build, una aplicación podría ser dev, una aplicación podría ser launch. Y todas hacen lo mismo, pero si estás cambiando de una aplicación a otra, no tienes forma de saber cómo comenzar en ella. No hay consistencia en esos scripts.

Muy bien, NX puede ayudarte a obtener los beneficios del estilo de codificación de Monorepo sin las desventajas de la co-ubicación de código. Ayuda al brindarte una ejecución de comandos más rápida, compartir código controlado, prácticas de codificación consistentes y un diagrama de arquitectura preciso. Cosas que ayudan con una ejecución de comandos más rápida, si usas Executors, que son básicamente como scripts de NPM, pero en scripts de NPM más estructurados básicamente. Entonces, hay herramientas a su alrededor que te ayudan a obtener autocompletado y obtener algo gráfico. Entonces, hay una consola de NX que te permite completar visualmente todas las opciones disponibles. La segunda cosa es que NX afectado te ayuda a ejecutar las pruebas en las cosas que realmente se ven afectadas por una PR. Por lo tanto, puedes ejecutar pruebas o compilaciones o cualquier comando solo en el código que se ve afectado por tu cambio. Eso acelera tu CI y tu desarrollo local y obtienes almacenamiento en caché local y distribuido. Entonces, si ejecutas un comando por segunda vez en el mismo código sin cambiar el código, será casi instantáneo. Se obtendrá de la caché en lugar de ejecutar el comando nuevamente. Y luego puedes usar el almacenamiento en caché distribuido, que te permite compartir esa caché en toda tu organización. Entonces, eso es NX Cloud y es un producto de pago. Aunque hay un gran nivel gratuito para NX Cloud. Entonces, la mayoría de las aplicaciones son gratuitas. Es así cuando llega a empresas gigantes, tienes que pagar algo. Muy bien. Obtienes compartir código controlado con NX. Puedes tener una API definida para tu biblioteca y decir, oye, si alguien va a usar esta biblioteca, estas son las cosas que se te permite usar. Si intentas acceder a algo que no exporté explícitamente en esta definición de la API, lanzará un error y tu código no se compilará. Puedes configurar etiquetas para decir qué bibliotecas y aplicaciones pueden depender entre sí y decir, estas pertenecen a este equipo y este conjunto completo de proyectos pertenece a este equipo y no pueden interactuar entre sí. Solo pueden depender de cosas compartidas. Puedes publicar fácilmente bibliotecas en NPM y puedes usar algo como el archivo de propietarios de código en GitHub, que requiere una aprobación de un conjunto específico de personas para cambios en un proyecto en particular, una sección en tu repositorio.

NX también te permite tener prácticas de codificación consistentes. Hay reglas de linting que te ayudan a determinar qué cosas dependen de qué otras cosas y hacer cumplir esas API y bibliotecas definidas. Los generadores son básicamente scripts que te permiten crear o modificar código. Hay un tipo especial de generadores llamados generadores de migración que actualizan tu código cuando actualizas versiones. Si pasas de React 16 a 17, hay un generador de migración que actualiza tus archivos de configuración para asegurarte de que tu código se mantenga actualizado junto con la actualización de tu marco de trabajo. Entonces, NARL tiene un conjunto de complementos que admiten diferentes marcos y herramientas, como Angular, React, Express, Nest, Next, Cypress, Storybook, cosas así. Y luego también hay complementos de la comunidad, por lo que NARL no tiene soporte incorporado para ellos. Hay una comunidad donde las personas escriben sus propios complementos para cosas como Vue y otras cosas, y puedes usar esos complementos de la comunidad para ayudar a hacer cumplir esas prácticas de codificación consistentes.

Muy bien, otra cosa que NX te brinda es un diagrama de arquitectura preciso. Entonces, si ejecutas NX graph en un repositorio que tiene NX instalado, puedes ver cuál es la estructura de código real de tu repositorio, no lo que deseas que sea o no lo que era hace seis meses, que es generalmente lo que es nuestro diagrama de arquitectura. Es lo que el código realmente es en este momento y cómo las diferentes partes de tu código realmente dependen entre sí. Y esto es realmente útil. Esta es una de las, no sé. Una de mis características favoritas de NX es este gráfico de dependencias.

Muy bien, así es como NX estructura tu repositorio de forma predeterminada. Entonces, si vas a la configuración ligera de NX, puedes estructurarlo como desees. Esto es solo lo predeterminado. Si te vas con todo en NX y dices, oye, NX, estructura mi repositorio por mí, esto es lo que NX hará. Pero si quieres usar NX en un repositorio con una estructura diferente, puedo mostrarte cómo hacerlo al final. Muy bien, NX tiene una carpeta de aplicaciones y una carpeta de bibliotecas de forma predeterminada.

Entonces, las aplicaciones son cualquier cosa que sea como, tiene un punto de entrada básicamente, se puede implementar en algún lugar. Mientras que las libs son cualquier otra cosa. Es como una pieza de código compartible. Entonces, una lib podría ser como una página en tu aplicación o una lib podría ser una biblioteca de UI, o podría ser como un conjunto de funciones de utilidad. Es solo una pieza de código reutilizable y compartible. Dist es donde se construyen las aplicaciones, las herramientas son para scripts, podrían ser los generadores de los que hablamos o scripts de base de datos o cualquier otra cosa. Entonces, workspace.JSON o en este taller, vamos a usar archivos project.json. Este es solo un archivo de configuración para NX en sí, que define cómo funciona el sistema de compilación, básicamente. Nx.Json tiene otro archivo de configuración, algunas configuraciones para NX en la raíz. Tsconfig.base.Json tiene algunas configuraciones globales de TypeScript, con la pieza principal aquí es que configura alias para diferentes bibliotecas en tu repositorio. Entonces, puedes importar bibliotecas en tu repositorio casi como si fueran paquetes npm, pero en realidad no se implementan en ningún lugar de npm. No se publican en npm, solo están dentro de tu repositorio, pero las importas como si fueran paquetes npm. Muy bien, para la mayoría de estos archivos de configuración, tienes una configuración a nivel de espacio de trabajo y una configuración a nivel de proyecto. El espacio de trabajo en este caso sería un tsconfig.json y hereda todo del tsconfig.based.json. Entonces, cualquier cosa a nivel de proyecto hereda de lo global. Entonces, si quieres cambiar algo en general, lo configuras a nivel de espacio de trabajo. Y si quieres cambiarlo solo para ese proyecto en particular, cambias esa configuración a nivel de proyecto. Lo mismo ocurre con las configuraciones de jest, tenemos una configuración a nivel de espacio de trabajo y una configuración a nivel de proyecto, configuración de jest, y puedes ver que tienes ES Lint y algunas otras cosas también que se configuran de la misma manera. Muy bien. Entonces, hoy vamos a pasar por estos laboratorios, laboratorio uno a través de once aquí en el repositorio. Y sí. Entonces, esto es lo que será el laboratorio uno. El laboratorio uno crea un nuevo espacio de trabajo, por lo que cuando ejecutas MPX create NX workspace, le das un nombre y el nombre te da tres cosas. Establece en qué directorio vas a crear esto, como si estuvieras clonando un repositorio, cuál será tu alias de ruta en tus importaciones de TypeScript. Entonces, estás en mi org / algún proyecto. Entonces, mi org es el alias de ruta. Y luego tu ámbito de MPM, si alguna vez publicaras, ya sabes, algo en una biblioteca en tu repositorio, en realidad lo publicarías en MPM, ese sería el ámbito de MPM para eso. Ahora, las tres cosas se pueden establecer en algo más si quieres. Pero esto es solo de forma predeterminada cuando creas un nuevo espacio de trabajo, estas tres cosas se establecen en la misma cadena. Y luego más adelante, obviamente puedes cambiarlas. Muy bien, este es el repositorio en el que estamos trabajando, taller de NX React y voy a hacer clic en, sí, siéntete libre de trabajar conmigo si quieres. Si no, puedes simplemente mirar. Depende totalmente de ti. Entonces, quieres, este laboratorio, los pasos son generar un nuevo espacio de trabajo NX vacío para una empresa ficticia llamada The Board Game Horde. Así que voy a llevar mi código de EE. UU. aquí, y queremos hacer, lo configuraré de esta manera. Muy bien, así que queremos hacer el npx create NX workspace, y lo vamos a configurar como Board Game Horde, por lo que es importante tener esta cadena exacta aquí, si no, parte del código que copiamos y pegamos más tarde no funcionará, solo tendrás que actualizar eso. Entonces, cuando ejecutas eso, obtienes diferentes opciones aquí, aplicaciones, NPM, TypeScript, puedes configurar algo con una aplicación React precreada para ti, muchas otras cosas, puedes hacer una configuración de React y Express, pero vamos a hacer esta de aplicaciones, la primera. Aplicaciones y estamos haciendo no para NxCloud. Ahora voy a salir de eso porque ya lo hice y no queremos esperar a que NPM instale las dependencias, pero esto es, tengo un montón de carpetas aquí que son cosas que hice más tarde. Ahí vamos, así es como se vería, solo muévelo, okay. Y eso debería ser, okay. Entonces, así es como se ve si ejecutas ese comando, tendrás un Workspace.json, que está vacío, no tiene proyectos en él. Nx.json, que tiene algunas opciones aquí. Puedes ver aquí está el ámbito de NPM. Si quieres cambiar eso, aquí es donde lo cambiarías. Esto dice cuál es tu rama base predeterminada. Podría ser main o master, o lo que tengas, a veces desarrollado, las personas tienen eso. Y luego algunas otras opciones aquí, las veremos más adelante. Esto está configurado para Nx Cloud, lo veremos más adelante, y todas estas cosas las veremos más adelante. Y quiero mostrar el TypeScript aquí, okay, estas son solo las opciones base de TypeScript aquí. Muy bien, eso fue el laboratorio uno. Entonces, ahora tienes un repositorio Nx predeterminado. Ahora vamos a entrar en los complementos. Los complementos son una colección de, tienen ejecutores y generadores. Entonces, la diferencia entre los ejecutores y los generadores, los generadores crean o modifican código, y los ejecutores hacen todo lo demás. Los ejecutores pueden construir, probar, analizar o implementar o básicamente cualquier otra cosa que puedas hacer con tu código que no sea crear nuevo código, para eso son los ejecutores. Y luego, Nx list te dará una lista de los complementos que están actualmente instalados en tu repositorio y algunos complementos que están disponibles para agregar. Un complemento es un paquete NPM. Entonces, lo agregas como lo harías con cualquier paquete NPM. Entonces, puedes hacer yarn add del nombre del complemento. Y una vez que se haya agregado, luego puedes, eso debería llamarse generadores. Luego puedes ejecutar el comando generate para ejecutar tu generador, tu codemod. Es como lo llama React. Entonces, ejecutas Nx generate, y luego le das el nombre del complemento y luego dos puntos y luego el nombre del generador al que estás haciendo referencia en ese complemento. Y luego cualquier opción que ese generador esté buscando. En este caso, busca un nombre para la, por lo que para el generador de aplicaciones React, solo necesita un nombre para la aplicación. Y luego hay un montón de otras banderas que puedes configurar para esto, el generador de aplicaciones también. Si necesitas ayuda para encontrar las banderas que están disponibles, puedes instalar el complemento edX console para VS Code. Y eso te permite, te da una interfaz de usuario. Entonces, puedes hacer clic y decir generar, y luego quiero generar una aplicación, y luego simplemente completas el formulario para configurar las banderas que deseas para ese generador. Entonces, tenemos complementos para todas estas cosas, generación de código para configurar React o Angular o Storybook o cosas de backend como Node y Nest y Next, o como herramientas auxiliares como Cypress o TS Linux, cosas así. Sí, también puedes crear tus propios generadores personalizados. Entonces, ya tuvimos una pregunta al respecto. Y estos son muy útiles para codificar la estructura de código específica de tus organizaciones, como cosas que haces todo el tiempo. Entonces, todos tienen un conjunto específico de cosas que hacen cuando crean una nueva página en su aplicación, formas específicas en que configuran las cosas. Y es bueno codificar eso en un script en lugar de tener una lista de verificación que las personas olvidan el paso siete todo el tiempo o lo que sea. Entonces, solo tener un script que ejecutan y que automáticamente lo haga de la misma manera cada vez. Eso es algo genial de hacer. Hacer que las computadoras hagan cosas en las que son buenas y permitir que las personas hagan cosas en las que son buenas. Muy bien. Entonces, hagamos el laboratorio dos. Muy bien, bajaré aquí, siguiente laboratorio. Entonces, vamos a generar una aplicación React. Entonces, una cosa, cuando ejecutamos esto, si ejecuto Nx ____ version, me da 14.3.1 es la versión de Nx que tengo. Si no tienes Nx instalado globalmente, esto no funcionará. Tendrías que hacer Npx Nx ____ version, o podrías hacer, ya sabes, instalarlo globalmente. Npmi-g ____ nrl-cli, o simplemente puedes hacer Npmi-g Nx y eso lo instalará globalmente, y luego no tienes que poner Npx delante cada vez. Muy bien, Nx list, hablamos de eso antes.

Permíteme, déjame asegurarme de que pueda ver, esto está enumerando todas las cosas que están instaladas, y esas no deberían estar allí. Así que permíteme, aquí, creo que es eliminar node_modules, instalar. De acuerdo. Así que había hecho algo de trabajo previo antes de esto, y estaba más avanzado en nuestro taller, y luego volví al principio de mi historial de Git y cuando ejecuté nx list, mostró todo lo que tenía en mi node_modules. De acuerdo, así que intentémoslo de nuevo. Nx list, ahí vamos. Esto es lo que esperaba ver. Entonces, todo lo que tengo instalado de forma predeterminada aquí, tengo el espacio de trabajo NW, un linter y algunas pruebas, solo pruebas, y eso es todo, pero tenemos otros complementos disponibles para nosotros y vamos a instalar el complemento normal de React aquí. Estos son los que proporciona Narwhal y estos son complementos de la comunidad que otras personas han escrito y Narwhal no los mantiene, pero podrían ser útiles para ti. Así que puedes echar un vistazo allí y ver esos.

Entonces, pasemos al siguiente paso aquí. Vamos a agregar yarn add, usaremos MpMis. MpMi-S. No creo que necesites el guión S, pero tal vez sí, no lo sé. Seguiré las instrucciones porque soy obediente. Agregaremos aquí el complemento React de Narwhal. Y luego para esta aplicación en particular, también vamos a instalar la biblioteca Material UI. Copiar eso. De acuerdo. Rápidamente, mientras se instala esto, a la pregunta de Timothy, ¿podrías mostrar el archivo de espacio de trabajo real rápidamente, Isaac? Sí. Timothy, si estás, así que no sé dónde entraste, Timothy, pero la forma en que estamos trabajando en esto es que en el laboratorio uno creamos nuestro propio repositorio. Así que ejecutamos ese comando npx create nx workspace, y ese es el repositorio con el que estamos trabajando. Voy a dejar el enlace al laboratorio de nuevo aquí, pero estamos usando el repositorio en GitHub, principalmente para nuestras instrucciones para cada laboratorio. Así que déjame dejar eso. Sí. Este es un comando que configurará tu repositorio por ti. Sí, sí, sí. Perfecto, gracias, Isaac. Bien, bien, bien, bien. De acuerdo, así que lo he instalado y he instalado MaterialUI. De acuerdo, así que ahora el Paso 5 aquí es usar el complemento normal de React para generar una aplicación React llamada Store. Entonces, este enlace te lleva a, no, supongo que no. De acuerdo, vamos a ir a nx.dev y vamos a buscar Aplicación React, y eso es lo que queremos, Aplicación React normal. Estos son los documentos que nos dicen cómo usar la Aplicación React normal, así que puedes leer eso si quieres, o quedarte en tus instrucciones aquí, y te dirá qué hacer. Así que puedes hacer nx generate, bien, no funciona en el fondo oscuro. De acuerdo, bueno, sé lo que dice aquí. Así que voy a hacer nx generate, narl React, no ReCAD, no Application, y lo llamaremos Store, porque aquí dice que lo llamemos Store, y dice asegúrate de agregar React Router y seleccionar SCSS como estilo cuando se te pregunte. Así que haremos esto, así que elegiremos SCSS, ¿te gustaría agregar React Router? Voy a decir que sí. De acuerdo. Bien, ahora veamos qué hizo eso. Así que creó este Store. También creó una sección Store End-to-End, con la que no vamos a hacer nada por ahora, pero más adelante al final del taller, agregaremos algunas pruebas de Cypress aquí. Así que creó el Store aquí y ahora mismo, no hay mucho pasando allí. Y en realidad déjame mostrarte. De acuerdo, bueno, antes de actualizar el código, voy a ejecutar NX Serve Store y me estoy saltando un poco. Veamos, 1200. Esta es la aplicación predeterminada que se genera para ti. Tiene algunos enlaces a la documentación y cosas así, pero vamos a continuar, estamos en el paso seis aquí. Queremos agregar un archivo API ficticio y este enlace aquí nos lleva al código que vamos a copiar. Así que vamos a copiar los contextos, eso es uno. Y luego, debajo de la fuente aquí, la tienda de aplicaciones, aquí. Sí, lo pondré debajo de la fuente aquí. Nuevo archivo, fakeapi.ts. Pegar el código que copié. Voy a guardar eso. Y luego, voy a actualizar el archivo app.tsx con el código de aquí. Copiar el contenido. Pegar eso. Y actualizar el CSS. Copiar contenido. De acuerdo. Ahora, volvamos a nuestras instrucciones. Así que no estoy dedicando mucho tiempo a las piezas específicas de React porque nuestro enfoque principal es NX, no React. De acuerdo. Los hemos puesto allí. Y luego necesitamos copiar las imágenes del juego. Así que las moveremos desde aquí. Necesitamos copiar las imágenes del juego. No está, así que los chicos. Y está bien. Sí. Eso es y queremos este. De acuerdo. Así que ahora tenemos, tres archivos de imagen aquí que vamos a poner en la carpeta de activos. Uno, dos, tres. De acuerdo. Así que tenemos esos activos allí. Y ahora vamos a servir nuestra, es como nuestros datos, pero lo haré de nuevo. Nx serve Store ejecuta la tienda en modo de desarrollo. Y volvemos a... Ahí vamos. Esta es nuestra aplicación inicial aquí. Todavía no hace mucho, pero tiene algo de estilo para Material y tiene algunos juegos falsos que podemos... De acuerdo. Así que voy a... comprometer estos cambios, lo llamaré laboratorio dos. Y si te quedas atascado, hay un archivo de solución que te da algunas pistas sobre qué hacer. De acuerdo, hemos usado el complemento React para hacer una aplicación React. Ahora vamos a profundizar en los ejecutores y en qué son.

Los ejecutores se definen en archivos project.json. En nuestro caso, se definen en los archivos project.json. Y se ven así, pueden tener cualquier nombre que desees, al igual que los scripts de NPM. Pero tienen una estructura interna. Si observas el ejecutor de prueba aquí en el lado derecho, tiene una propiedad builder o executor que indica qué ejecutor usar. Y luego tiene un objeto de opciones que será diferente según el ejecutor que estés ejecutando. Pero en este caso, apunta a donde se almacena JesConfig y donde se encuentra el archivo tsconfig. Es una forma estructurada de configurar los comandos que puedes ejecutar en tu proyecto.

Para ejecutar un ejecutor, puedes usar nx run y luego el nombre del proyecto y luego dos puntos y luego tu objetivo, que puede ser build, lint o serve, y luego las opciones que correspondan. Por ejemplo, para servir mi aplicación, puedes hacer nx run my app serve. Y también puedes abreviar eso si quieres. Esta es la forma que uso con más frecuencia. Haces nx y luego el objetivo y luego un espacio y luego tu proyecto y luego las opciones vienen después de eso. Así que nx serve my app, nx build my app y nx test my app. Eso es lo que suelo escribir. Además, puedes usar nx console para ejecutar estos y obtienes el mismo formulario para completar. Debería mostrar eso, mostrar eso a continuación. Muy bien. Compartiré mi pantalla. Muy bien, vamos a ir al laboratorio tres. De acuerdo. Entonces vamos a, necesitamos compilar la aplicación. Para compilar la aplicación, al igual que hicimos, hicimos nx serve store antes para compilarlo. Vamos a hacer nx build store y se ejecuta nx build store. Está procesando. Y se ejecutó correctamente el objetivo. Entonces, la forma en que nx sabe cuáles son esos nombres y cómo buscar esas cosas. Si miras aquí, hay este archivo project.json dentro de la carpeta app store project.json. Y tenemos esta propiedad de objetivos aquí, debajo tenemos build y serve, lint y test. Así que podemos ejecutar nx lint store y ejecutar el linter. Podríamos ejecutar nx test store, esto probablemente fallará. Las pruebas unitarias no se han actualizado. Sí. ¿Podrías demostrarlo, si vas al archivo project.json, si estás usando el complemento NX console, también verás estos pequeños enlaces de texto en la parte superior. Puedes usarlos para ejecutar los objetivos también. Sí, estas cosas, esto proviene del complemento NX console aquí. Así que si simplemente haces clic en esto y eso ejecutará nx build o serve, lo que sea. NX console en sí está aquí. Así que si quiero construir algo, puedo hacer clic en build y luego hacer clic en el proyecto que quiero construir. O puedo encontrar el proyecto y luego hacer clic en build aquí y ejecutarlo. Así que hay múltiples formas diferentes. Si vas aquí, muestra un formulario que puedes completar con cualquier otra bandera que quieras establecer en eso. De acuerdo, construir allí. Así que deberíamos tener una carpeta dist. Vamos a ver eso. Aplicaciones, así que carpeta dist. Así que tenemos App Store. Esta es la salida de compilación de App Store. Y lo has construido. Objetos, así que acabamos de hacer eso. De acuerdo, veamos si podemos encontrar aquí, mira las opciones bajo build. Está utilizando el ejecutor Gnarl webpack. Así que está utilizando webpack internamente, también está utilizando Babel. Esta es la ruta de salida donde se envía. Usa el archivo de índice. Así que esta opción de assets aquí. Esta es la carpeta donde se encuentran nuestros activos, imágenes. Y se copian porque lo estamos configurando aquí. Así que si tuviéramos otros activos, podríamos poner la ruta a alguna otra carpeta de activos aquí, no sé, imágenes. Y se copiarían. Y todas estas opciones están definidas en la documentación de cada complemento. Sí. Genial. Envía una bandera al ejecutor para que compile para producción. Creo que se compila para producción de forma predeterminada. Déjame ver. El siguiente build store. Y puedes ver aquí, esto sucede casi al instante debido a la caché. Así que se compiló para producción de forma predeterminada. Entonces, si quieres compilar para desarrollo, puedes hacer doble guión configuración, desarrollo. Y se compilará... Entonces no tendrás los hash, los hashes en los archivos porque se compiló para desarrollo. Si miras en dist aquí, la salida es diferente. Pero está bien. Esas configuraciones y ese archivo project JSON también, creo. Sí. Sí. Entonces tenemos dos configuraciones diferentes configuradas aquí. Hay una configuración de desarrollo y una configuración de producción. Ambas configuraciones heredan de estas son las opciones globales. Y luego desarrollo toma estas y las sobrescribe con estas opciones. Es como hacer una asignación de objetos. Lo mismo con producción. Toma lo que está aquí arriba y luego lo sobrescribe con esto, con las opciones que se establecen aquí abajo. Así que puedes configurar cuantas configuraciones desees y desarrollo y producción no son cadenas mágicas. Puedes tenerlas como cualquier cadena que desees. Sí, iba a mostrarte eso cuando hacemos las diferentes configuraciones, no solo almacena en caché lo último que se ingresó. Lo almacena en caché durante una semana, todas las diferentes configuraciones posibles. Así que puedo ir y venir entre cosas y están en caché. De acuerdo, abre la carpeta dist.

Notamos que las cosas son diferentes y también podemos ver que hay este serve aquí. Este ejecutor de serve, básicamente toma este comando de construcción de store. Por lo tanto, utiliza la configuración que se establece aquí, y luego lo construye en modo de desarrollo. Así que en realidad lo está sirviendo. Entonces, si quieres cambiar, cualquier opción que cambies aquí arriba también afectará la salida de serve aquí abajo. Oh. De acuerdo. Muy bien, ahora hagamos... De acuerdo, hemos creado una aplicación, ahora hagamos una biblioteca. En general, tenemos cuatro tipos diferentes de bibliotecas y puedes estructurar las bibliotecas como desees, pero estas son algunas convenciones de nombres que hemos encontrado útiles. Entonces tienes bibliotecas feature, que son cosas como una ruta, como una página, biblioteca UI, son componentes de presentación, enfocados solo en la interfaz de usuario, y luego las bibliotecas data se enfocan en interactuar con, como hacer, obtener cosas de la red o manejar el acceso a tus datos locales, cosas como Redux o cómo gestionar tu almacenamiento de esa manera. Y luego tenemos bibliotecas util, que son simplemente funciones de utilidad en JavaScript puro que pueden ser utilizadas por cualquier cosa. En general, querrías tener, solo tienes bibliotecas feature, las bibliotecas feature pueden importar cualquiera de las otras tres. Las bibliotecas UI solo pueden importar util, y data solo puede importar util, y luego util solo puede importar otras bibliotecas util. Así te aseguras de que no tengas una función util que importe de una biblioteca feature y las cosas se confundan y tengas dependencias cíclicas y cosas así. También puedes estructurar tus directorios como desees, pero en general, es bueno tener bibliotecas específicas de la aplicación en una carpeta con el nombre de esa aplicación. Entonces, si tenemos bibliotecas basadas en la, que están destinadas a ser utilizadas en la aplicación store las colocamos debajo de una carpeta store en libs y las cosas que se comparten entre múltiples aplicaciones, las colocamos en una carpeta compartida.

Ahora, si, después de haber colocado algo, una biblioteca en algún lugar y quieres moverla a otro lugar, es fácil mover las cosas con un generador y llegaremos a eso en el laboratorio nueve. Así que no te preocupes demasiado por dónde colocas las cosas. En general, tienes este debate sobre, ¿debería, tengo algún código nuevo para poner y está esta pregunta de si debería crear una nueva biblioteca para poner este código? ¿O debería agregarlo a una biblioteca existente? Entonces NX es, el bloque de construcción básico de NX es la biblioteca o el proyecto. Y cuanto más dividas las cosas, más NX puede ayudarte. Cuanto más te ayudará el almacenamiento en caché, más te ayudará el comando efectivo, más el gráfico del proyecto puede brindarte conocimientos sobre cómo está estructurado tu código. Ahora, obviamente, puedes exagerar con eso. Si tienes 1,000 proyectos, tu gráfico de proyectos ya no es útil porque hay demasiado en marcha. Y hay más archivos de configuración que archivos de código en ese punto. O tienes que, ya sabes, tienes que ir a siete bibliotecas diferentes para completar cualquier tarea. Así que, ya sabes, utiliza tu propio criterio, pero si sientes que NX no te está ayudando lo suficiente, o tienes demasiados fallos de caché, entonces es posible que desees dividir las cosas más. Y si sientes que, ya sabes, es difícil entender las características porque están divididas en demasiadas bibliotecas, tal vez tienes demasiadas bibliotecas y necesitas consolidar más el código. Así que es un compromiso, y depende de ti cuánto divides y cuánto combinas. Esto es lo que te ofrece el gráfico de dependencias, una disposición visual de tu base de código. Y haremos una demostración de eso en un momento. Vamos a hacer el Laboratorio cuatro.

Muy bien, aquí. Laboratorio cuatro. Oh, en realidad no es el Laboratorio cuatro, tenemos un pequeño interludio, Laboratorio 3.1. Entonces, si quieres saltar a un laboratorio específico en nuestra masterclass aquí, tenemos algunos scripts de migración, algunos generadores que te ayudarán a saltar a un laboratorio específico en nuestra masterclass. La forma de hacerlo es ejecutar la instalación, esta es la dependencia de desarrollo, NxReactWorkshop. Este es un complemento, es un complemento muy sencillo, no tiene ejecutores, solo generadores. Y no querrías usar esto en un, es un complemento solo para esta masterclass. No querrías usarlo en tu código de producción, simplemente no es útil. Y hagamos, entonces agregamos eso, y, luego vamos a ejecutar, en realidad, hagamos todas las instrucciones reales, 0.0.1. 0.0.1.

De acuerdo, estoy instalando una versión antigua de este complemento, y te mostraré cómo se ven los generadores de migración. De acuerdo, déjame, déjame salir, tres, de acuerdo. De acuerdo, entonces queremos migrar a la última versión de este complemento. Y Nx tiene un, el comando para hacer esto es Nx migrate, y luego le das el nombre del complemento que quieres migrar. React, Workshop. Y puedes hacerlo con latest, o eso es, ya sabes, latest es el valor predeterminado. Y lo que hace es ir y buscar desde npm la última versión de este complemento, y luego dice, oye, ¿hay algún generador de migración entre lo que tienes instalado actualmente en tu repositorio, y lo que tienes instalado actualmente y lo que está en latest en npm. Y lo que va a hacer es, colapsar esto. Va a crear un archivo migrations.json, que es un conjunto de instrucciones sobre qué scripts debe ejecutar. Entonces, la razón por la que hay este paso, no ejecuta inmediatamente las migraciones porque en bases de código muy grandes, podrías tener, no sé, 15 generadores para ejecutar en una actualización y a veces no siempre funcionan automáticamente. Y así quieres poder confirmar tus cambios. Si has realizado algunas de las migraciones y no todas, quieres poder confirmar ese archivo de migraciones y así no quedarte muy rezagado en el ritmo de la rama principal. Y así puedes confirmarlo y puedes ejecutar los scripts en múltiples PR diferentes, básicamente. Este archivo de migraciones aquí tiene todos los diferentes generadores de migración que están en este paquete. Y en nuestro caso, cada generador es un laboratorio en particular o completar el laboratorio uno, completar el laboratorio dos, completar el laboratorio tres. Y si ejecutara esto en realidad en la terminal, te dice qué hacer. Así que ejecuté NxMigrate. Ejecutas npm install, y luego ejecutas NxMigrate, ejecutas migrations para ejecutar los scripts. Así que si hago mi... Lo que esto hará, esto completará toda la masterclass hasta el segundo día, lo cual no sé si realmente queremos hacer. Creo que vamos a omitir el paso cinco aquí y pasar al paso seis, que es realmente útil. El paso seis es en lugar de ejecutar todos los scripts de migración, así que podríamos editar manualmente esto y decir, en realidad, solo quiero ejecutar hasta el laboratorio tres, así que voy a eliminar todos esos y solo hacer estos, uno, dos y tres. O puedes hacer solo uno, o puedes ejecutar este generador aquí y ejecutar generate, y NARWAL-NX React Workshop Complete Labs, y hay algunas opciones diferentes, así que puedo hacer desde el laboratorio uno hasta, hacer una prueba en seco, mostrándome qué va a suceder, desde el laboratorio uno hasta el laboratorio tres, y eso hará el rango aquí, o puedo hacer, solo quiero ejecutar el script para el laboratorio cuatro, porque ya estoy en el laboratorio tres, solo quiero ejecutar el script para completarlo, así que si ejecuto esto, en realidad no ejecutó el script, solo creó el archivo de migraciones, y luego para migrarlo, ejecutamos esto, se asume que migrations.json, así que no tienes que agregar equals allí. Entonces, básicamente, este generador actualizó esto, y dijo que solo ponga el script del laboratorio cuatro aquí, y así que si ejecuto eso, y es migrate run migrations, de acuerdo, esto ha completado el laboratorio cuatro para mí. Vamos a ver los pasos para el laboratorio cuatro para ver qué hizo en realidad. Este es el laboratorio 3.1, así que básicamente esta es una forma de saltar a cualquier paso en el que quieras estar en la masterclass. Así que el laboratorio cuatro era crear una component library. Así que hicimos, dijimos que creara una nueva biblioteca de React llamada uishared y que la colocara en la carpeta libs store. Así que veamos. Así que generador, así lo hacemos. Está dentro de aquí lib store uishared. Así que básicamente lo que hizo fue NX generate, narwhal, React library, y luego lo llamamos uishared y luego lo colocamos en el directorio de libs, en realidad de store. Ese es el comando que ejecuté para hacer eso. Oye Isaac, lo siento, tenemos una pregunta en el chat aquí de Timothy. Para las cosas del laboratorio 3.1, ¿realmente necesitamos ejecutar esa migración o si nos la perdimos, podemos simplemente continuar? Sí, puedes omitir el 3.1. El 3.1 es opcional. Solo está ahí para ayudar a las personas si quieren saltar a un laboratorio específico. Entonces, sí. Así que es completamente opcional, pero es útil para moverse entre los laboratorios si quieres. Y también es útil para presentarte la función de migración de NX, que, ya sabes, es una función bastante poderosa. Sí, hay mucho chat en el chat sobre la migración y lo genial que es. Así que, genial. Pero sí, lo siento por interrumpir. Adelante, Isaac. Permíteme enviar el enlace aquí nuevamente. De acuerdo, eso fue el paso dos para crear esta store, Store UI shared. Luego vamos a generar un nuevo componente React. Así que en lugar de hacer esto desde la línea de comandos, lo haré usando NX console solo para mostrar las diferentes formas de hacerlo. Así que simplemente voy a escribir componente aquí y me muestra todos los generadores que tienen componente en el nombre. Así que quiero crear un componente React, este, no una historia de storybook o una especificación de cypress. Así que quiero eso y queremos llamarlo header. Así que en realidad no estoy haciendo clic en ejecutar en ninguna de estas cosas porque ya ejecuté ese script, pero solo te muestro lo que harías para hacerlo. Así que haces esto y asegúrate de que el componente generado se exporte automáticamente. Quieres asegurarte de que se exporte. Haz clic en eso, asegúrate de que esté configurado en true. Desde la línea de comandos sería. Desde la línea de comandos, harías el flag dash dash export. Y eso crearía este componente header. Y luego se supone que debes copiar este código que ya se ha copiado. Así que copia y pega este código desde aquí. Haz estilos, todo esto copiado allí. Y luego usamos ese componente header en el archivo app.tsx aquí. Así que lo estamos usando, estamos importando el header desde aquí. Entonces, esta línea roja aquí es porque TypeScript no se ha puesto al día con el hecho de que se ha creado la nueva biblioteca. Entonces, si te encuentras con eso, si haces TypeScript restart ts server, eso debería solucionar esa línea roja allí. Sí, eso está solucionado. Eso, y así que aquí están las instrucciones sobre eso. Ahora, ¿por qué es eso? Oh, es minúscula h. Así que eso no debería ser h minúscula. Eso debería ser H mayúscula. De acuerdo. Y necesito arreglar nuestro script de migración. No se está copiando correctamente. De acuerdo. De acuerdo. Ahora hemos servido los proyectos y C, así que ahora deberíamos tener un header. Así que para servir el proyecto, hacemos nx serve store de nuevo, y vamos aquí y actualizamos esto. Y ahí está nuestro header. Está un poco aplastado porque lo hice pequeño, pero de acuerdo. Ese gato parece extra gruñón cuando está aplastado con él.

Muy bien. Creo que eso es el final de ese laboratorio. Oh, entonces, veamos el gráfico de dependencias. Esa es una buena idea. Buena idea, persona que escribió la masterclass. Nx graph. Así que escribe Nx graph. Oh, creo que la palabra no es. Lo siento, continúa. Está bien. De acuerdo. Así que escribe Nx graph y muestra qué proyectos hay en tu repositorio. Así que tenemos algunas pruebas de extremo a extremo, que aún no hemos escrito. Tenemos la aplicación store y luego tenemos nuestra biblioteca de UI. Y puedes ver que las líneas aquí son dependencias entre los diferentes proyectos. Esta línea implícita aquí solo significa que es una dependencia definida manualmente. Las pruebas de extremo a extremo en realidad no tienen una importación de TypeScript de nada en la aplicación store. Así que Nx no sabría que hay una dependencia allí a menos que se lo indiques, que hay una dependencia. Mientras que esta línea aquí, hay, si haces clic en ella aquí, te dice en este archivo app.tsx, hay una importación de la biblioteca store UI shared. La biblioteca compartida de la interfaz de usuario de la tienda. Y puedes ver que está aquí. App.tsx. Así que esta es la línea que hace que esa dependencia ocurra. Y si lo comentara, déjame comentarlo. Y así esto no se construirá más, pero detendremos esto y ejecutaremos Nx graph de nuevo y mostraremos todos los proyectos y mira, no hay dependencia. Así que Nx es lo suficientemente inteligente como para saber si realmente tienes una dependencia o no. De acuerdo, eso fue el laboratorio 4. Laboratorio 4. Podemos hacer que este sea el laboratorio 4. De acuerdo, hagamos otro laboratorio y luego haremos un descanso. De acuerdo, laboratorio 5. Así que tenemos una biblioteca de interfaz de usuario. Vamos a hacer una biblioteca de utilidades. Entonces esto va a almacenar solo algunas funciones o puede almacenar algunos tipos de TypeScript, sería otro buen ejemplo de una biblioteca de utilidades. Así que si ves aquí, estas calificaciones son números sin sentido. Eso no es lo que querrías ver si estuvieras en una tienda. Así que vamos a corregir el formato de esas y hacer una biblioteca de utilidades compartida que agregará formato a esas calificaciones. Así que queremos que las calificaciones se vean así, bueno, 1.9 de 10, o 7.4 de 10 en lugar de lo que teníamos ahí arriba. Así que hagamos... Vamos a hacer una nueva biblioteca desde el paquete de espacio de trabajo NARAL. Esta biblioteca no tiene nada que ver con React. Es solo una función pura de JavaScript. Así que vamos a hacer una... En realidad, esto puede que no sea correcto. Déjame ver si esto es... Vamos a hacer una nueva biblioteca aquí. Y en realidad, sí, esto es... Vamos a hacer una biblioteca de NARALJS, porque eso tiene más sentido, porque es JavaScript. Y lo llamaremos utilformatters. Así que le estamos poniendo el prefijo util- para comunicar que es una biblioteca de utilidades. Y luego lo colocamos en la carpeta store. Así que utilformatters. Aquí tenemos esta ejecución en seco. Esto te muestra qué archivos se crearían. Pero queremos que esté dentro de, queremos que esté dentro de libs/store. No queremos que esté en la raíz aquí. Queremos actualizar este directorio aquí. Así que establecemos store allí, déjame ver, okay sí. Esas son, estas son las ubicaciones en las que queremos crear estos archivos. Así que si estamos satisfechos con eso, déjame verificar de nuevo. De acuerdo, lo vamos a poner allí. Lo vamos a llamar así. Creo que eso es todo, de acuerdo. Así que cuando estemos satisfechos, hacemos clic en ejecutar aquí. Y podemos ir aquí. Y así tenemos UIShared y tenemos util formatters. Así que dentro de aquí tenemos store utilformatters. Esto es solo lo predeterminado. Queremos obtener el código que vamos a copiar desde aquí. Así que vamos a hacer una función formatRating. Y lo establecemos así. Y exportamos todo allí. Solo para que sepas, este archivo index.ts aquí, esta es la API definida para esta biblioteca. Así que si tuviéramos, entraremos en esto un poco más tarde, creo, pero si tuviéramos export const secret o llámalo no uses esto igual a dos. Y si no lo exportamos explícitamente aquí, en realidad eso no es, veamos cómo hacer esto. Así que ahora estamos exportando todo desde allí. Podríamos hacer solo export formatRating. Export formatRating. Así que si hiciéramos esto y alguien intentara usar la constante don't use this, Nx lanzará un error de linting y dirá, oye, no puedes, no puedes hacer commit de este PR. Estás usando cosas que no se supone que debes usar. Así que esta es nuestra API aquí. Mientras que si haces export star, eso significa, oye, todo lo que está dentro de esta carpeta está permitido. Sí, eso está permitido. Así que he hecho eso. Formatters, quieres usarlo en tu proyecto de frontend para formatear la calificación de cada juego. Así que vamos a hacer la importación y luego actualizar nuestra calificación en app.tsx. Copiemos esto. Apache.txt. FormattRating, y veamos dónde está esto. FormattRating. De acuerdo.

Muy bien. Vamos a servir esto. Next serve store. Fresh. Y nuestras calificaciones están formateadas. Así que eso está funcionando. Y si miramos el NxGraph, mostrar todos los proyectos, ahora puedes ver la aplicación store está utilizando tanto la biblioteca UI shared como también está utilizando la biblioteca util formatters. Muy bien. Muy bien. Así que vamos a hacer una pausa aquí. Laboratorio seis. Así que vamos a crear una biblioteca de rutas o biblioteca de funciones. Vamos a... Ahora mismo tenemos una lista de todos los juegos en nuestra tienda. Queremos tener una vista detallada de los juegos de mesa individuales. Así que vamos a crear una nueva biblioteca de React llamada feature game detail. Y la vamos a colocar dentro del directorio store. Y vamos a configurar algunas rutas automáticas para nosotros. Así que hagamos... De acuerdo. Así que vamos a generar una biblioteca. Queremos que sea una biblioteca de React llamada feature game detail. Y la queremos en el directorio store y en el proyecto de la aplicación raíz, la vamos a llamar store. Básicamente esto está agregando automáticamente la ruta al proyecto de la aplicación store. ¿Hay algo más aquí que queramos configurar? No creo. No creo que necesitemos configurar eso. Esto está generando una biblioteca con rutas. Esto es si quisiéramos que la biblioteca en sí tuviera rutas dentro de ella, pero no necesitamos hacer eso. Sí, de acuerdo, así que vamos a ejecutar eso. Y ver qué ha creado. Así que tenemos esa feature game detail. Se creó para nosotros y en nuestro app.tsx agregó estas rutas al app.tsx para nosotros. Así que agregó algunos enlaces y estas rutas y nos dio este feature game detail. Así que no necesitamos estas rutas como page one y page two aquí. Solo queremos esta ruta. Y volveré a las instrucciones aquí. Así que hicimos ese cambio en la ruta para obtener el ID del juego de la URL. Así que queremos que la ruta incluya el ID en la URL allí. Así que no está ahí de esta manera. De acuerdo, toma mi ID de ahí, completa el componente con los archivos proporcionados. Así que queremos store feature game details. Voy a copiar eso. Así que ahora estamos usando el parámetro de ruta para especificar qué ID de juego estamos mostrando. Voy a obtener los estilos aquí. Está justo aquí. Esto parece nuevo. Luego veamos. Hacer clic en cada tarjeta en app.tsx para ir allí. Así que vamos a envolver la tarjeta con este enlace aquí. Así que en nuestro app.tsx, en lugar de tener estas cosas de enlace aquí, deshazte de ellas. Y queremos que cada tarjeta aquí. Enlace alrededor de eso. Mueve la tarjeta dentro de ese enlace. Y esta clave ya no es necesaria en la tarjeta, tendremos la clave en el propio enlace. Así que enlaza a eso y luego la clave allí. Sí. De acuerdo, vamos a servir esto y ver si funciona. Enlace. Vamos a servir store. ¿Funcionó? Algunos estilos extraños. Pero parece que funciona, así que se está actualizando esto, esta es la ruta aquí abajo. Veamos, ¿por qué hizo eso el estilo? ¿Olvidamos algún paso? Voy a hacer eso, TSX. ¿Nos olvidamos del SCSX? No, tengo el SCS, esto es solo para el feature game detail. Así que estoy buscando si hay un, oh, aquí, vamos a hacer una depuración en vivo. De acuerdo. Sí, apaga esa declaración de texto creo. Sí, correcto. Sí, de acuerdo. Quiero decir, es solo que no hay, extraño, de acuerdo. Agrega eso a nuestro app CSS. donde necesitamos hacer esto ahora mismo es solo un poco exagerado con eso, digamos simplemente, agregar una declaración nunca podrás aprenderlo. Ahí vamos, eso es suficiente. Así que verificamos el servidor y el gráfico de dependencias y puedes ver que el feature game detail está siendo referenciado por el servidor. Muy bien, sigamos adelante.

Laboratorio siete. Ok, aquí es donde se pone emocionante. Vamos a agregar una API del backend. Hasta ahora solo hemos tenido una aplicación en nuestro repositorio y ahora vamos a agregar un nuevo un nuevo complemento, el complemento Express. Vamos a hacer una aplicación de backend. Así que hemos estado sirviendo los detalles del juego para esta API falsa. Queremos hacer una API real ahora. Ok, genial, una nueva aplicación llamada API desde el complemento Express, y la llamaremos y queremos configurar el proxy para Store. Ok. Así que voy a usar la consola de Next para asegurarme de elegir el correcto y hacerlo una aplicación. Y ahora, ahora tenemos Express como una opción aquí, porque acabo de agregarlo. Ahora la aplicación Express, la vamos a llamar API y el proyecto frontend aquí. Lo que esto hace es configurar la configuración de proxy para nosotros durante el desarrollo. Si ejecuto esto, esta opción de proyecto frontend crea... si puedo encontrarlo... Oh, no, creo que está en aquí.

Aquí, este archivo. Ahora, cuando ejecuto la tienda, cuando sirvo la tienda, se redirigirán automáticamente todas las solicitudes de API a este puerto local para que cuando sirva... Puedo servir la API y puedo servir la tienda, y sabrán el uno del otro. De acuerdo. Copia el código de la API falsa aquí. Aplicaciones API source app game super repository. De acuerdo. Entonces vas a copiar esto y subir aquí a... Necesitamos crear esa carpeta SourceAppGames.Repo repository.ts. Iniciar repository.ts. De acuerdo. Así que copiamos eso y déjame ver esto para asegurarme de que lo copié. Sí, eso es todo. Y luego actualizamos la carpeta o archivo ExpressMain.ts para usar ese repositorio. Así que solo está sirviendo los juegos y sirviendo juegos individuales aquí. De acuerdo. Así que ahora no estamos sirviendo cosas todavía, pero solo mira el gráfico aquí. Puedes ver que tenemos una API. No está conectada a nada, pero está ahí. Guardemos esto. Creo que esto es el laboratorio siete. Guardaré esto como laboratorio siete. Muy bien. Hemos hecho eso. Hemos hecho todo aquí. De acuerdo. Ahora vamos al laboratorio ocho. Muy bien. Ahora vamos a conectar la aplicación frontend para usar la API del backend, realmente hacer una llamada de red y algo realmente aparecerá en la pestaña de red. Bien. Vamos a eliminar el archivo fake API.ts. Eso es lo que hemos hecho en el paso uno. Cuando uses fetch en el componente app.tsx, así que voy a hacer clic aquí. Veamos dónde está fetch. Sí, aquí es donde se realiza una llamada de red real. Así que copiaremos esto. Stores, app.tsx. Deberíamos poder ver. Hagamos eso. Los cambios aquí. Tenemos nuestro estado de carga de datos, tenemos un useEffect aquí. Realiza una llamada de red real y establece el estado cuando regresa. De acuerdo, eso funciona aquí. Lo actualizamos. Luego, vamos a servir la API. Y luego vamos a servir la tienda al mismo tiempo pero en una terminal diferente. Así que sirvamos la API. Luego nx serve store. Observa que la API está en el puerto 3333. Y nuestra tienda está en el puerto 4200. Si miras la configuración de proxy, esto le dice a la tienda que si vas a /API y buscas esta API en el puerto 3333. Así que actualiza esto y momento de la verdad. Veamos la pestaña de red. Así que funcionó. Verifiquemos nuevamente. Realmente está usando la pestaña de red y aquí vamos. Se está cargando desde la pestaña de red. Y si hago clic en uno individual, tal vez no haga una llamada de red adicional para los individuales, pero realmente está haciendo una llamada de red aquí. Tenemos una API que realmente funciona. Debería verse igual, puedes ver que está haciendo una llamada de red a /games. De acuerdo. Sigamos adelante. El servidor frontend se está utilizando en diferentes puertos. De acuerdo. Llamándolo a través del archivo proxy config.json. De acuerdo, ahora actualicemos la vista de detalle del juego individual. En lugar de usar la API falsa para obtener sus propios datos como esto. Así que copiaremos esto. Vamos a feature game detail.tsx. Y solo intenta ejecutar aquí. De acuerdo, lo tenemos. CSS. ¿Por qué necesita un CSS diferente? Oh, porque estamos haciendo... De acuerdo, estamos actualizando la ruta GameDetail para mostrar más información en lugar de solo el ID. De acuerdo. Estamos usando la función FormatRating compartida aquí. Aquí. Entonces, ahora esto se está utilizando no solo en la aplicación de ruta, sino también en esta biblioteca aquí. Esta es una función util que se utiliza en varios lugares. De acuerdo. Ahora vamos a servirlo y ver cómo se ve esto. Ya se está sirviendo. No puedo resolver el módulo GameDetail, eso es... En sentido... De acuerdo. Store featured... De acuerdo.

Permítanme actualizar esto. Bien, entonces... Ahora, tenemos una vista detallada aquí abajo. Tiene un botón de compra y compartir. Cosas más interesantes. ¡Funciona! ¡Hurra! Bien, quiero mostrarles el gráfico de dependencias aquí. Ahora que tenemos varias aplicaciones. Sí, después del gráfico de dependencias, ¿puedes mostrar también un poco la configuración del proxy? Sí, claro. Puedo mostrar eso de nuevo. Así que todavía tenemos la API por separado. No importa nada de la tienda, no comparte nada. Pero puedes ver el detalle del juego. Tanto el detalle del juego como la aplicación de la tienda dependen de esta biblioteca storeUtilformatters. Así que si hacemos clic en este enlace aquí, la app.tsx lo importa y el gameDetail.tsx lo importa, hace que ese enlace suceda aquí. Así que, sí, genial. Sí, y puedo mostrarte el archivo de configuración del proxy. Así que esto está dentro de la raíz de la aplicación de la tienda. Y simplemente dice, cada vez que esta aplicación realiza una solicitud que comienza con /API, en lugar de buscarla en localhost:4200 o donde se esté sirviendo esta aplicación, la busco en otro localhost:3333. Y esto obviamente solo es para desarrollo. Cuando lo construyas y lo sirvas en producción, copiarías tu aplicación Express desplegable en la carpeta /API, y colocarías la aplicación de la tienda en la raíz. ¿Podrías mostrar también el archivo project.json para mostrar cómo se vincula ese archivo de configuración del proxy? ¡Sí! Sí. Aquí, veamos, ¿dónde está? Aquí vamos. Así que debajo de serve, hay una opción llamada proxy config, y es simplemente la ruta hacia ese archivo de configuración del proxy. Sí, y también te darás cuenta, lo siento, Isaac, solo quería responder a la pregunta de Phillip porque estaba preguntando sobre eso. Si vas a esa línea, eso se agregó en el laboratorio siete, que fue recientemente. Cuando generamos la aplicación API, en realidad especificamos que esta aplicación de la tienda la iba a estar usando, y eso es lo que configuró esta configuración del proxy. Todo se generó automáticamente para nosotros. Lo pasamos por alto un poco. Sí, déjame mostrarte. Esta configuración aquí, así que cuando lo llamé API, voy a hacer uno nuevo llamado, bueno, no lo haré, pero API2, y luego estableces el proyecto frontend aquí. Y esto está diciendo, eh, agrega una configuración de proxy a la tienda. Así que esto es... Sí, solo quería decir, puedes verlo en las salidas de ejecución en seco para ver qué proceso obtienes. Está actualizando ese archivo, y está actualizando... Bueno, en realidad no es el project.json porque ya había una configuración de proxy. Así que esta vez solo agregó un segundo proxy, pero la primera vez también lo habría modificado. Así que... Sí. Genial, gracias, Isaac. Claro. Muy bien. ¿Alguien ha intentado usar los scripts de migración para saltar a un laboratorio en particular? Me pregunto si eso ha sido útil para alguien. Sí, tendremos una grabación. De acuerdo. Bueno, Timothy lo está intentando ahora, pero tal vez podamos seguir adelante. Muy bien, tenemos una hora. Espero poder completar el Laboratorio 11 y luego me gustaría hacer una pequeña demostración de cómo empezar desde un repositorio existente y agregar pequeñas mejoras de NX, que es básicamente lo que la mayoría de ustedes hará si tienen un repositorio existente en su trabajo y quieren comenzar a agregar NX. Muy bien, hagamos el Laboratorio 9. Así que, Laboratorio 9, queremos compartir código entre, vamos a codificar la conexión entre la API y el frontend para decir, eh, tenemos este tipo de juego, la definición de lo que es un juego. Y si eso cambia, tanto la API como el frontend deben cambiar. Entonces, podemos codificar eso con algunos tipos de TypeScript y podemos compartirlos entre las dos aplicaciones diferentes. Entonces, cada vez que eso cambie, podemos actualizar esas cosas. Así que, haremos una nueva biblioteca llamada util interface. Y la pondremos dentro de la carpeta API. De acuerdo. Crear una biblioteca. Puedes llamarla workspace o JavaScript. Me gusta llamarla JavaScript util interface. Eso es lo que quería. Y la pondremos en la carpeta API. De acuerdo. Creo que eso es todo lo que necesitamos. Sí. Ahora ejecuta eso. Y ahora tenemos esta util interface de API aquí. Y vamos a importarla aquí. GamesRepository.ts. Así que vamos a usar esta nueva interfaz en nuestro archivo de repositorio de juegos. Nuestro espacio de nombres. Estos son unos juegos geniales.

Y construyamos la API. Ve y asígnala aquí. Ahora, una cosa interesante, puedes notar esto, es cuando ejecuté Nx build API, Nx mostró este mensaje que dice que está esperando que una tarea de proyecto dependiente termine. Si miramos nuestro gráfico aquí, Nx vio que la API depende de la API util interface. Y dijo, oh, así que antes de construir la API, necesito construir la API util interface. Y así intentaba hacer eso antes de construir Nx API en sí mismo. Curioso. Sí. Entonces, Nx API util interface tiene un comando de construcción, que si es solo una biblioteca de tipos de TypeScript, eso no tiene mucho sentido. Así que podríamos simplemente ir aquí y eliminar eso. Sí. Creo que hay una opción cuando ejecutas el generador para la biblioteca, puedes especificar si es construible o no. Eso creará ese objetivo de construcción. Así que si elimino esos objetivos y lo ejecuto de nuevo. Y luego Nx build API. Esta vez, no mostró ese mensaje porque vio que, aunque todavía depende de la API Util interface, no hay un objetivo de construcción allí. Así que no intenta construirlo. Pero eso puede ahorrarte muchos dolores de cabeza si estás tratando de construir algo y no te das cuenta de que no has construido una biblioteca. Entonces, ¿en qué paso estamos aquí? OK, hemos construido eso. Inspeccionemos el gráfico de dependencias. OK, nuestra tienda de frontend mantiene una lista de juegos en el estado, pero actualmente está tipada como any, así que necesitamos compartir esa interfaz de juego. Así que ahora vamos a usar el generador de movimiento. Vamos a mover la interfaz util a la raíz. OK, la raíz de la carpeta libs. De acuerdo, podemos hacer eso. Así que vamos a ejecutar. Me gusta, así que puedes hacerlo desde la línea de comandos, generate-nrwall-workspace-move, y luego dash-dash help para averiguar cuáles son las opciones. Veamos, move. Y luego este es un ejemplo que mueve libs my-feature-lib a libs shared my-feature-lib. Así que el proyecto my-feature-lib y luego lo mueve aquí. Así que puedes hacer eso. Me gusta usar la consola NX. Así que voy a seguir haciendo eso. Entonces, Isaac, recientemente agregamos algo a la consola NX 2 donde puedes hacer clic derecho en un proyecto en el directorio de archivos, y estará en el menú. ¿En el directorio de archivos? ¿Ni siquiera en la consola NX en sí misma? Sí, simplemente puedes hacer clic derecho allí. Y en la parte inferior, dice mover proyecto NX. Mover proyecto NX. Oh, genial. De acuerdo. De acuerdo. Vamos a hacerlo en vivo. Así que eso simplemente muestra esto, es genial. De acuerdo. Eso es increíble. Sí. Sí. Así que movimiento de carpetas Para las personas que están viendo, es interesante porque mover es como mover cosas no generar cosas en realidad. Pero aún encaja, como ese mecanismo de cambiar los archivos fuente en tu repositorio. Así que lo que estamos haciendo es mover una biblioteca. Pero aún estamos usando el mecanismo del generador para hacer esto. Así que por eso lo pongo aquí. Porque esto es más que simplemente mover la carpeta. Si solo mueves la carpeta, tendrías mucho código roto, referencias rotas a ella. Así que esto, puedes ver aquí en esta ejecución en seco, está actualizando esta otra aplicación aquí. Está actualizando los caminos de TSConfig. Y está actualizando el archivo workspace.json. Y además de hacer todo el movimiento de carpetas. Así que voy a ejecutar esto. Así que está tomando APIUtilInterface y luego moviéndolo al nivel raíz util interface. Este es el nuevo nombre aquí. Y puedes ver, asegúrate de que esté. ¿El laboratorio quería que lo moviéramos a Shared? ¿O fue? No, bueno, el laboratorio dice, muévelo a la raíz. OK, tienes razón. Lo siento. Tal vez se supone que lo movamos de nuevo. Sí, esperaría ponerlo en Shared, pero. Pero las instrucciones dicen moverlo a la raíz. Entonces, no sé. Sigamos las instrucciones entonces. Lo siento. Supongo que debí recordarlo mal. Así que sí, este es un buen ejemplo de algo que tendría sentido poner en una carpeta Shared. OK, eso está ahí. Y asegurémonos. Bueno, veamos qué más tenemos. Desencadenar la compilación de todo y ver el gráfico de dependencias. Así que NxBuildAPI. Así que eso todavía funciona. NxBuildStore. Así que está construyendo proyectos dependientes allí. Así que eso todavía funciona. Y veamos el gráfico. Oh, no actualicé la tienda en sí. Así que nuestra tienda de frontend hace esto. Así que hicimos el movimiento. Y luego queremos, sí, no hicimos el paso 9 aquí. Necesitamos usar realmente estos tipos en la aplicación de frontend. Y NX pudo decirnos eso al mirar el gráfico..tsx, eso es 1, data aquí es un juego, OK, lo pondremos aquí, bien. Así que ahora si hacemos NX graph, ahí vamos, ahora tanto la tienda como la API están usando esta interfaz util. ¡Ta-da! Es genial, me encanta eso.

Ahora, no sé, he pasado suficiente tiempo trabajando en proyectos donde tienes un repositorio separado para el backend y cada vez que cambias algo, como la apariencia del cuerpo de la solicitud o la apariencia del cuerpo de la respuesta, coordinar eso entre repositorios es realmente difícil. Así que me encanta esta parte, tener un solo lugar para la interfaz de TypeScript es increíble. Sí.

De acuerdo. Muy bien. Así que vamos a repasar esto. Veamos el complemento de Storybook, vamos a generar algunas historias de Storybook para nuestro componente de interfaz de usuario, el componente de interfaz de usuario del encabezado. Déjame ver, eso fue el Laboratorio 9, creo. Y vamos a hacer, instalar el complemento de Storybook estrecho. De acuerdo. Y luego vamos a ejecutar el generador de configuración de Storybook en el proyecto de historias compartidas. Configuración de Storybook. La configuración de Storybook de React, eso es lo que queremos. Hazlo en, ¿por qué no? Store. ¿Store you I shared? Sí. Sí. Así que ese es el nombre correcto. Esto configura algunos archivos de configuración de storybook para nosotros. Y queremos decir sí, crear automáticamente historias de Cypress. Generar automáticamente historias para nosotros. Y vamos a ejecutar esto. Diciendo sí a todas esas preguntas. Así que si lo ejecutáramos desde la línea de comandos, habría indicaciones que dirían, ¿quieres que esto se marque? ¿Y quieres que esto se marque? ¿Y quieres que esto se marque? Bueno, esto se está generando para Timothy. De hecho, acabamos de pasar al laboratorio 10. Así que simplemente haz clic en el siguiente laboratorio en la parte inferior de ese archivo al que te acabo de enviar el enlace.

Así que asegúrate de cambiar esas cosas antes de eliminarlas de node modules. Pero eso es lo único que tendrías que hacer, sí. Genial, y sí, Jose tenía una pregunta sobre dependencias como Storybook y Cypress. ¿Las versiones se bloquean a la versión de NX que estás usando o puedes cambiar y usar la que quieras? Así que sí, puedes cambiar, usar la versión que quieras sin garantías de que funcione. NX actualiza las versiones por ti. Y si te adhieres a las versiones de esos paquetes que NX te proporciona, podemos garantizar que funcionarán juntos. Pero si comienzas a actualizar tu versión de TypeScript, esa es a menudo la que la gente quiere actualizar más rápido. Quieres actualizar TypeScript o quieres actualizar tu framework de React o cualquier otro a la última versión, puedes hacerlo, pero entonces estás adelantándote a los scripts de migración que tenemos. Básicamente, estamos tratando de, mientras lo mantenemos, hacer esas actualizaciones como tú. Y tan pronto como hayamos descubierto la mejor manera de hacerlo y los mejores scripts de migración para todos, los publicaremos. Así que si quieres ir rápido, puedes lidiar con esos puntos problemáticos tú mismo. Pero si quieres sentarte y esperar a que hagamos el trabajo, también puedes hacerlo. Genial. Tenemos una pregunta más detallada aquí de David. Pero hagamos la demostración primero y luego intentaremos abordar eso.

Vamos a hacer la instalación. Así que este es el repositorio de paquetes de Netlify CMS aquí. Puedes ver que es un archivo learner json. Tiene un archivo learner json. Sé muy poco sobre esto, aparte de que tiene un archivo learner y ejecuté un pequeño video agregando X a él. Pero cuando lo obtuve por primera vez, no tenía antecedentes sobre este repositorio. No es como si estuviera hecho a medida para funcionar bien con NX o algo así. Pero básicamente, para obtener los beneficios del almacenamiento en caché de NX y el gráfico, eso es muy sencillo. Es muy fácil si estás utilizando algo como Yarn workspaces o Lerna. Y cuando NPM termine de instalar, puedo mostrarte cómo hacerlo. Así que básicamente, para instalar NX, para ejecutar el NPX, el NX graph, ni siquiera necesitas instalar NX en absoluto. Así que puedo ejecutar NPX NX graph aquí. Y déjame mostrarte el package JSON de esto, solo para que sepas que no tengo ningún secreto. No hay narwhal ni nada aquí. No estoy ocultando nada. Y solo voy a ejecutar NPX NX graph aquí. Y... Vaya, pensé que funcionaba. Lo intenté antes. Pensé que había una opción que necesitabas pasarle. Déjame ver si puedo encontrarlo. Sí, tal vez sea eso. Oh. Cuando esto termine, lo veremos. Estoy buscando el archivo de Twitter de Victor porque es el último lugar que recuerdo. Definitivamente estaba allí. Veamos. Entonces, tal vez solo necesitas agregar NX al package.json. Sé que eso funcionará, si agregas NX al package.json debería funcionar. De acuerdo. Bien, la instalación de MPM ha terminado. MPX NX-graph, sí, todavía no le gusta eso. De acuerdo, voy a hacer MPMY-D NX. Agregando NX como dependencia de desarrollo. De acuerdo, solo lo agregaré. Ahí vamos. Bien, lo único que hice, los únicos cambios son el package lock y el package JSON. Y ahora se ha creado, podemos ver cómo se ve el gráfico del proyecto para este repositorio. Es un poco difícil ver exactamente qué está sucediendo. Así que podría ser mejor, vamos a hacer clic en una de estas cosas. Vamos a ver, no sé, tal vez esta. Y vamos a enfocarnos en eso. Ahora solo está mirando los proyectos que dependen directamente de este. Están vinculados a un enlace de distancia de este. Así que ves que el archivo Widgets depende de la aplicación y del widget CMS. Y luego este también depende de la interfaz de usuario predeterminada de CMS. Otra cosa que puedes hacer es dar un paso más y ir a dos pasos de distancia. Y ahora estos son los proyectos disponibles. Y tres pasos de distancia y cuatro pasos de distancia, parece que dos pasos de distancia es lo máximo que se puede hacer. Y también puedes agruparlos por carpeta. Parece que todos están en la carpeta de paquetes. Así que eso no nos dice mucho. Pero sí, eso es algo que puedes hacer. También puedes excluir manualmente cosas. Puedes hacer clic en esto y excluirlo. Así que ahora solo hay tres cosas. Eso es útil. Y veamos, ¿qué más podemos hacer? Ejecutemos. Veamos. Ahora, para usar NX en sí, si ejecutas NPX add NX to Monorepo. Esto funciona en un repositorio de aprendizaje y en Yarn workspaces. Creo que esas son las dos cosas principales. Básicamente, cosas que tienen archivos package JSON que definen los proyectos separados. Si ejecuto eso, eso también agrega NX a tu package JSON, pero también agrega otro archivo. Creo que agregará un archivo NX.JSON a la raíz aquí. Así que esto, todo esto sin y puedes elegir si decir sí o no a NX Cloud. Claro, diremos que sí. NX Cloud, ni siquiera lo he demostrado. Es bastante sorprendente la primera vez que lo ves en acción. En lugar de simplemente almacenar en caché en tu máquina, estás almacenando en caché tus comandos en toda tu organización. Ejecuto una construcción en mi máquina y luego quiero que Zach revise mi PR. Él puede revisar el PR que he enviado a GitHub y ejecuta la construcción en su máquina y es una construcción instantánea porque todo lo que sucede es que descarga la salida de ese comando de construcción en su máquina. No tiene que ejecutar la construcción en sí. De acuerdo, esto es lo que acaba de cambiar. Parece que tenemos un bloqueo de Yarn y un bloqueo de paquete, pero básicamente el único cambio es el archivo NX.JSON. El package JSON solo tiene esto, tiene NX y agregamos NX Cloud porque dijimos que sí. Así que solo usa el archivo NX.JSON y ahora podemos, oh, veamos. Sí, NX Console incluso funciona. De acuerdo, no tenemos ejecutores definidos. Todo sigue en scripts de NPM. No tenemos archivos project.JSON, nada, así que ninguno de los complementos de los que hablamos, como no hay narwhal normal. NX Migrate no funcionará. ¿Qué más no funcionará? Probablemente la mayoría de los generadores no funcionarán. Como los generadores de bibliotecas y aplicaciones no funcionarán, pero probablemente los generadores de componentes sí funcionarán. Es un poco hit or miss con esos generadores, pero puedes crear tus propios generadores. Eso debería funcionar, pero de todos modos, cambios mínimos aquí. Sucede en cinco minutos y ahora podemos ejecutar. Ejecutemos la construcción en algo que esté cerca de la parte inferior aquí, NX build. Así que esto se está ejecutando, esto se está ejecutando la construcción en Netlify CMS lib widgets.

Y no hay nada personalizado en esto. Ni siquiera sé qué comando se está ejecutando. Algo, veamos, cross M que se está ejecutando Webpack aquí y tardó 4.7 segundos. Si lo ejecuto de nuevo, hago clic en ejecutar de nuevo, esta vez tardó 0.65 segundos porque estaba en caché. Y eso es todo prácticamente sin cambios.

Déjame buscar el script aquí, CMS lib widgets aquí. Lib widgets. Sí, estoy buscando los paquetes en. Así que básicamente se está ejecutando este script. Este es el script que acabo de ejecutar. Así que NX pudo encontrarlo y. Oh, lo siento, hay una pregunta en el chat. ¿Cómo se agregó el archivo NxJson? ¿Cuál fue el comando? Sí, el archivo NxJson se agregó ejecutando npx add Nx to mono-repo. Sí, y todo lo que hace ese comando es hacer una instalación de NPM en Nx mismo y agrega un archivo Nx.json. Y obtienes almacenamiento en caché, obtienes Nx console, puedes usar Nx cloud. Puedes obtener almacenamiento en caché distribuido de esa manera. ¿Qué más obtienes con eso? Sí, esas son las cosas principales.

Entonces, si quieres migrar esto, aprovechar algunos de los plugins, podrías, veamos, veamos si esto funciona. Bueno, voy a tener que hacer esto de forma un poco vaga y no hacerlo realmente. Pero podrías crear un archivo project.json. Y probablemente lo que haría es copiar un archivo project.json existente. Y pegarlo aquí. Este es un mal ejemplo porque es uno de Cypress. Hagamos un, testimonio. Debería obtener una aplicación, probablemente. Pero de todos modos, copias uno existente y luego actualizas tus ejecutores aquí para usar lo que quieras agregar. Y luego puedes, uno a la vez migrar proyectos para usar los plugins si quieres. O si no quieres usar los plugins, podrías, y solo te gusta este formato de tener cosas en el project.json en lugar de los scripts de npm, podrías hacer npm script build. Así que voy a copiar esto, project.json, simplemente voy a borrar todo aquí. De acuerdo, voy a hacer esto, esto es build, y narwhal workspace, hay un ejecutor de comandos de ejecución aquí. Y, y aquí, solo estoy pegando el script de MPM. Esto debería funcionar aquí. Eso, de acuerdo, y ahora voy a ejecutar, Netlify CMS lib widgets. Nx build netlify CMS lib widgets. De acuerdo, no funcionó. Oh, narwhal workspace no está instalado. De acuerdo, necesito instalar eso. Mi guión D, en narwhals slash workspace. Así que esto es, a medida que te involucras más, te adentras más en el ecosistema de Nx, quieres empezar a usar algunos de los plugins. Debes instalar el plugin primero. ¿Qué estamos haciendo? Entonces, lo que hace este ejecutor de comandos de ejecución es simplemente ejecutar este comando en la terminal. Así que es básicamente lo mismo que el script de MPM, pero está en este formato diferente aquí. Y te permite acercarte más, si tu objetivo es acercarte más a la configuración de plugins entonces esto te acerca más a ese formato. Y puedes hacer cosas poco a poco. Entonces, lo otro, creo que esto debería funcionar sin un archivo workspace.json de nivel superior. De acuerdo, veamos si eso funciona. No se puede encontrar el módulo. Y, ¿se puede instalar ese todavía o no? Así son las alegrías de la demostración en vivo. Es nx. ¿Eso es lo que se llama? No quería instalarlo, sí. De acuerdo, así que hay otra cosa que debo configurar en nuestro proyecto, Jason aquí, una de las opciones es configurar el directorio de trabajo actual del, y queremos que el directorio de trabajo actual sea este, copiar en la ruta. De acuerdo, así que queremos que el directorio de trabajo actual sea aquí. Así que debes estar en esta carpeta y luego ejecutar esto. Oh, vamos. Error de compilación del módulo. De acuerdo, bueno, voy a dejar de depurar esto, pero básicamente eso es lo que, esos son los pasos que tomarías. Lo haces uno a la vez y comienzas a mover las cosas. Pero para obtener el nivel básico de funcionalidad de NX, se tarda cinco minutos. Y obtienes almacenamiento en caché y obtienes, y obtienes tu, tu NX console y el gráfico de NX funcionando de serie. Entonces, probablemente puedas ver mi pantalla ahora, así que estoy a la izquierda, estoy con el chico LAB10 guide y aquí a la izquierda, la aplicación con el estado actual al final de LAB9, así que solo sigo allí y sí, ya he instalado esto. De acuerdo. De acuerdo, luego voy a la consola y voy aquí y hago algo con storyboard. ¿Ese? Sí. Así que ese se abre. Y store UI shared. Y store UI shared en el nombre del proyecto. Sí. Y todo lo demás ya está marcado, así que debería estar bien. Y luego presiono ejecutar. Luego toma unos segundos, copia esto. Y luego cambia. Creo que está hecho. Si te desplazas hacia abajo. No. Cambió. Creo que está hecho. En teoría debería funcionar después de eso, ¿verdad? Así que quiero decir. Sí. Debería. De acuerdo. Entonces, cierra la terminal y pega el comando y presiona Enter. Oh, este es un mensaje de error diferente al que tenía antes. ¿Me faltó algo? No creo. Bien. ¿Puedes ver tu estructura de archivos? Sí, aquí. De acuerdo. No se encontraron configuradores en tu configurador. Documentos, Story, My Shared Story book. ¿Puedes ver la carpeta storybook ahí?.

Sí, justo ahí. Entonces no se creó nada allí, ese es un problema. Hagamos, intenta eliminar esa carpeta, la carpeta .storybook. Sí. Y luego desplázate hacia arriba hasta la parte superior y elimina el .storybook en la parte superior. Sí. Entonces. Y ejecutemos esto, el generador nuevamente. De acuerdo, generar. Ya está ahí, solo puedes hacer clic en ejecutar nuevamente. De acuerdo. De acuerdo, ya existe. De acuerdo. Ve a, sí, supongo que puedes simplemente eliminarlo. Debería funcionar o puedes hacer en la, lo siento, en la interfaz de usuario, la interfaz de usuario de la consola, desmarca generar especificaciones de Cypress en el lado derecho. Hay algunas casillas de verificación en ese formulario allí. ¿Aquí? Sí. Entonces sí, desmarca esa, configura Cypress y desmarca generar especificaciones de Cypress. De acuerdo. Ahí lo tienes. Intentemos eso. De acuerdo. Y ahora echemos un vistazo dentro de esas carpetas .storybook. Asegúrate de que, sí, eso está, ahora tienes cosas allí. De acuerdo. Eso es lo que, eso es lo que debería estar allí. De acuerdo. ¿Debería intentarlo de nuevo? Sí, intenta ejecutar un xstorybook. Ah, esto parece, oh. Este es en realidad el error que obtuve antes, así que. Error de compilación del módulo. Sobre digital. Interesante. Y aquí está, bien. De acuerdo. Así que intentemos. Desplázate hasta el final. Asegúrate, ¿puedes hacer un nx build store? Asegúrate de que eso funcione. Hay, de acuerdo, eso funcionó. ¿Puedes mirar el archivo package.json de nivel raíz? Oh, package.json. Entonces no, este es en realidad el incorrecto. Este. Sí, asegurémonos de que todos los paquetes de narwhal sean 1431, parece que todos están bien. Veamos el paquete de nivel raíz. De acuerdo, eso está bien. De acuerdo, déjame ver mi versión y ver si hay alguna diferencia. No estaba siguiendo toda la conversación, pero la gente en el chat sugiere verificar la versión de Node. Oh sí, no lo hicimos. Esa es una buena idea. Entonces eso podría ser. De acuerdo, luego usemos nbn use 16. Tal vez porque sé que hubo algunos problemas antes con la versión 17, tal vez esto solucione el problema. De acuerdo, déjame retractarme. No, 17 no funciona con store. Hay algunos elogios para los generadores de espacios de trabajo, así que. De acuerdo. Entonces, si vas a crear un generador de espacios de trabajo, nx generate workspace generator, y lo llamaré, digamos que quieres establecer eso cada vez que hagas una aplicación React, siempre será SCSS. Así que hagamos eso. Entonces mi org app. Estas son las configuraciones que siempre usamos en nuestra organización. ¿Qué es esto? Parece que está haciendo una instalación de npm. De acuerdo. Intentémoslo nuevamente, así que lo aclararé. De acuerdo, intentémoslo de nuevo. OK, bueno de todos modos, cuando ejecutas ese generador, crea este archivo aquí. Y voy a usar el narwhal. Voy a importar los generadores de react de narwhal y voy a importar el generador de aplicaciones. Desde allí. Y así es solo una función. Una función asíncrona, por lo que este árbol es una especie de representación en memoria del árbol de archivos. Y luego el esquema son las opciones que el usuario pasa cuando ejecuta el generador. Así que voy a decir que voy a pasar las. Todas las opciones de esquema. Pero voy a ver si podemos. Debería estar allí. Voy a conocer react. Sí, ahí está el generador de aplicaciones. Y este es el esquema del generador de aplicaciones para la aplicación react incorporada. Permíteme ver si puedo, vamos a la interfaz del esquema. De acuerdo, eso no se explota en ningún lugar. Así que no puedo, no puedo usar eso directamente. Bueno, simplemente voy a hacer esto. Voy a copiar esto. Bueno, simplemente lo estableceremos como any por ahora. Esquema any, así que vamos a pegar cualquier esquema y luego queremos establecer el estilo CSS en SCSS. Entonces, sin importar lo que pasen, vamos a establecer el estilo CSS en, en SCSS. Estilo, sí, estilo, y voy a establecer la propiedad en, en SCSS porque eso es lo que usamos en nuestra organización. Luego este paso de formato de archivo es simplemente, ejecuta el comando de formato de índice, que básicamente ejecuta prettier, y esto puede ejecutar la instalación de npm al final si actualizas algún paquete. Así que vamos a intentarlo.

Y luego, lo otro es que tienes este archivo schema.json, que define todas las propiedades que puedes pasar. Y en nuestro caso, nuestro esquema sería nombre, el string, porque coincide con lo que se definió aquí. Permíteme revisar esto. ¿Por qué está molesto? De acuerdo. Entonces el generador de aplicaciones espera algunas cosas como omitir formato, ejecutor de pruebas unitarias, ejecutor de pruebas E2E y linter. Bueno, aquí, bueno, simplemente lo estableceremos como any y veremos si se queja por esto.

Entonces, para ejecutar nuestro generador de espacios de trabajo, ejecutamos Nx workspace generator, ya sea my org app, y luego le damos un nombre. No puedo encontrar aplicaciones en eso. Sí, veo eso usuario. Hay algo raro en este repositorio para mí, pero creo que lo he creado. Aplicaciones API app store. No, no lo creó. De acuerdo, ¿qué está pasando? No puedo encontrar aplicaciones en ese usuario, no veo. ¿Tu PWD coincide con tu espacio de trabajo actual? Me ha pasado recientemente con VS code. Creo que sí. De acuerdo. Creo que fue algo con el que estoy haciendo cosas raras allí. De acuerdo, bueno, eso está haciendo cosas raras. Permíteme intentar con andRhinoConsole aquí. Así puedo ejecutar generate. Esta es la tarea básica que se está ejecutando aquí. Solo está renderizando. Entonces, este generador de espacios de trabajo aparece en el mismo lugar que los generadores normales. E incluso sabe según mi archivo de esquema qué propiedades puedo pasar. Puedes ver que pasas algunas aplicaciones. ¿Y esto funcionará? No, tiene el mismo problema. De acuerdo, simplificaré el código, supongo. De acuerdo, veamos. Aquí vamos. De acuerdo, se está ejecutando. Y muestra algunas aplicaciones. Y si pudiera averiguar por qué no funciona. Debería poder ejecutar este generador y especificar las aplicaciones que sea. Tal vez algo raro con eso. Apuesto a que es, en realidad requiere las cosas que dice que requiere. Mi TypeScript Any realmente no me está ayudando. Sé lo que estoy haciendo pero en realidad no sé lo que estoy haciendo. Genial. Sí. Con la API para esto, también encuentro que es extremadamente útil. Porque el árbol que se pasa a esta función funciona casi como un sistema de archivos virtual. Entonces, a medida que haces estas cosas, cada una de esas funciones que estamos importando aquí es como hacer uno de esos cambios en un sistema de archivos virtual que te mostrará. Sí, Isaac está usando la API en este momento para mostrar cómo se haría eso. Y lo que esto admite es que luego puedes ejecutar esto con la bandera dry run y en realidad te mostrará, como vimos en VS code, el complemento para NxConsole, antes de ejecutarlo realmente, te mostrará los archivos que se generarán y los archivos que se actualizarán, etc. Entonces, hace que esa parte sea muy, muy útil. Así que simplemente agregué un, hice un tree that write file a test.txt. Y esto es un dry run. Así que me está diciendo que va a crear este archivo test.txt. Y si lo ejecuto aquí, lo ejecuté y ahí está nuestro archivo que acabo de crear. Genial.

Creo que esto no está relacionado, Isaac, pero hay algunas preguntas interesantes sobre el versionado. Entonces, José pregunta si puedes ver la pregunta de José allí. Es una pregunta interesante, especialmente a la luz del enfoque de una sola versión versus un enfoque de aprendiz, si quieres responder la pregunta. Sí. Entonces, el enfoque de estilo de aprendiz es que tienes múltiples package JSON, tienes un package JSON para cada proyecto en tu repositorio. Y cada vez que haces un cambio en un proyecto, incrementas el número de versión para eso, y luego otros paquetes dependen de él, ¿verdad? Mientras que el estilo de Google es que cada proyecto se crea para funcionar con todos los demás proyectos en la misma confirmación. Así es como funciona la idea de las confirmaciones atómicas. Entonces, si vas a seguir la filosofía de confirmación atómica, entonces dices que en esta confirmación para este repositorio, cada paquete debería poder funcionar con cada otro paquete. Entonces, si sigues esa estrategia, no tienes que preocuparte por el versionado. El versionado no tiene sentido a menos que vayas a publicar en npm para los proyectos que están fuera de este repositorio. Luego lo versionas y lo publicas en ese momento. Pero los proyectos dentro de tu repositorio, no deberían necesitar una versión. Deberían funcionar juntos, si están en la misma confirmación, a menos que estés utilizando el estilo de aprendiz y luego tienes que preocuparte por esas cosas. Sí, entonces un detalle interesante de esto también es que el propio NX Workspace utiliza NX. Y, publicamos eso en un repositorio externo, en npm. En realidad, tengo un pequeño proyecto de código abierto para la gestión del estado que ejecuto yo mismo que hace algo similar. Entonces, el detalle interesante de esto, si estás en algo similar, es que a menudo, cada vez que publico el paquete o cada vez que NX publica el paquete, incrementamos cada paquete que exportamos, incluso si no se ha modificado, porque queremos mantener todas esas cosas en la misma versión principal. Así que, sí, no sé, eso puede ser útil para tu situación o no. En general, la respuesta de Isaac tiene más sentido para la mayoría de ustedes, supongo. Es como, si este es tu mono repositorio, este es tu mono repositorio, así que sí. Y aumentar todos los paquetes es un problema interesante para hacer esta pregunta. Es solo un script, como escribir un script de node que lo haga. Sí, sí. Básicamente eso haces, pero tienes que aumentarlo en todos tus package JSON en el NX y luego publicarlos y luego aumentar la versión principal, etc. Así que se vuelve un poco extraño. Pero NX, si simplemente revisas el código fuente de NX si estás interesado, puedes ver cómo lo están haciendo. Sí. Entonces, por eso, cuando estamos solucionando problemas en nuestra masterclass, quieres asegurarte de que todos tus paquetes de NX estén en la misma versión, porque si todos están en la misma versión, deberían funcionar juntos. Pero si están desactualizados, comenzarán a hacer referencia a cosas que no existen en los otros paquetes. Sí, creo que nos estamos quedando sin tiempo aquí. Algunas personas están tratando de irse a dormir. Sí. Gracias a todos por venir. Creo que hemos respondido todas las preguntas.