El Estado del Estado en el Enrutador de la Aplicación

Muy bien. Sí, soy Jack Harrington. No solo soy un ingeniero FullStack como muchos de ustedes, estoy seguro. También soy YouTuber. Así que tengo este canal de YouTube llamado Blue Collar Coder, y allí cubro una variedad de diferentes temas. Entonces, mucho de React, obviamente. Y hablo mucho sobre la gestión de estado. Así que cubro detalles en profundidad sobre eso, y hablo mucho sobre el AppRouter, porque está junto a la S y es muy popular, y es el nuevo router, y recibo muchos comentarios porque cubro muchas de estas cosas. Como, oye, ¿cómo uso mi tienda Redux en el AppRouter? Y yo estoy como, esa es una pregunta interesante. Así que hice un montón de codificación para ver por mí mismo, cómo lo haría. Y sabía en ese momento, estaba como, hmm, esto parece funcionar. Definitivamente funciona, pero tal vez esta no es la forma correcta. Así que saqué un video. Boom. Y en realidad lo hizo bastante bien. A la gente pareció gustarle por el lado de los comentarios. De hecho, cuando lo bajé, porque hay algunos anti-patrones en él, estaban como, ¿dónde se fue? Pero recibí algunos comentarios del equipo de React y del equipo de Next.js, como, ya sabes, hay algunas cosas que no deberías hacer allí. Así que lo que estoy aquí para hacer hoy es darles toda la experiencia que aprendí de eso. Volví y hice mucha más codificación, obtuve muchos más comentarios. Y lo que espero presentarles hoy son algunas reglas pragmáticas básicas sobre cómo usar un administrador de estado de manera adecuada y segura. Y tal vez si deberías o no en el App Writer.

Y es interesante, volvamos al principio de todo esto. Así que el pensamiento común en torno a React ha sido... Quiero decir, solo ha existido durante diez años. Pero durante la mayor parte de ese tiempo, o gran parte de él, hemos tenido los componentes de clase, y this.state y this.setState. Y eso no era genial, desde un punto de vista de gestión de estado. Por eso te encuentras con cosas como Redux, MobX, para hacerlo una mejor experiencia.

Pero ahora, tienes que pensar de manera diferente al respecto. Porque tenemos una mejor gestión de estado incorporada directamente en React. Tienes useState, useReducer, useRef para almacenar un estado. Tienes useCallback, useMemo, useEffect para escuchar los cambios en los estados. Y eso es básicamente un sistema de gestión de estado reactivo incorporado directamente en el núcleo de React. Así que tal vez no necesitamos un administrador de estado.

Y luego, encima de eso, tenemos Next.js, y el operador tiene el estado de ruta. Tienes las rutas parametrizadas, tienes los parámetros, tienes searchParamsState. Si miras a Lee Robinson, hizo un fantástico video recientemente sobre cómo usar searchParamsState para mantener el estado y gestionar el estado en una aplicación Next.js. Tienes el estado del formulario, tienes acciones del servidor, tienes revalidación, puedes hacer cosas como HTMX y tener desarrollo impulsado por el servidor. Así que el resultado final es la regla número 0, es posible que no necesites un administrador de estado. Así que piensa en eso primero. Cuando pienses en tu nuevo proyecto o en migrar, sabes, tal vez un administrador de estado no va a ser parte de eso.

Es raro. Vienes con una charla sobre gestión de estado, y soy el tipo que te dice que tal vez no necesites un administrador de estado. Pero tal vez estás como, oh, estoy realmente triste. Amo mi administrador de estado. Me encanta cómo funciona. No quiero hacer matrices de dependencia. Así que está bien. Permíteme darte algunos consejos de seguridad para hacerlo de manera segura si aún quieres usar una tienda Redux. Así que la regla número 1, no hay estado global. ¿Qué quiero decir con eso? Bueno, está bien, pensemos en un global. Tienes tu tienda de configuración aquí.

Esta es la React Toolkit. Tal vez algunos de ustedes estén familiarizados con esto. Si vas a usar Redux toolkit, si vas a usar Redux, por favor usa Redux toolkit.

¿Entonces cuál es el problema con esto? Bueno, el problema es este. El global. Esta es literalmente una variable global. Y en el escritor de páginas, esto realmente no era un problema. Es algo bastante simple. Obtén props del lado del servidor. Ve y haz algún tipo de cosas asíncronas. Y luego eventualmente solo haces un renderizado de árbol. Y el renderizado del árbol es síncrono. Así que hey, haz una tienda. Lo que sea. Está bien. No es gran cosa.

Podemos tener algunos problemas donde de solicitud a solicitud. Podrías tener superposición de solicitudes. Pero no es gran cosa. Sin embargo, el escritor de aplicaciones, eso es algo diferente. Así que digamos que obtienes la solicitud uno. Tienes un renderizado de árbol. Y como parte del renderizado del árbol tienes componentes asíncronos en el árbol. Así que va y establece la solicitud uno, establece la tienda a su solicitud uno. Luego se va y comienza a hacer algún trabajo. Estoy bloqueado. Pero ahora el servidor es como, está bien, tomaré otra solicitud y estableceré esa tienda al segundo estado para esa solicitud. Así que ahora tengo data de la segunda solicitud en memoria, en el servidor de la primera... Eso va a entrar en la primera solicitud muy fácilmente. Porque eso va a ir y luego acceder a esos data, como quién es el usuario actual, todo ese tipo de cosas.

Y va a sangrar data. Así que eso no es genial. Por eso no quieres usar globales.

Así que para poner esto en un contexto más práctico, hagamos una tienda de donuts y dragones. Y esto va a estar en el escritor de aplicaciones, así que tendrás un diseño en la parte superior que sostiene toda la página. Tendrás un encabezado y luego un pop-up de carrito. Tendrás el contenido de la página, así que esto es como una página de e-commerce.

Y los que realmente nos interesan son estos dos componentes, el pop-up del carrito y el pop-up de añadir al carrito. Porque esos son componentes del cliente, van a mutar el estado, va a ser mutable. Y es entonces cuando queremos usar algo, tal vez, como un gestor de estado o no. Simplemente usemos el contexto. Si miras esto y piensas, oh, eso es tan simplista, todo lo que tienes es un número, sí, eso es cierto. Sabes, quiero decir, probablemente no necesitas usar un gestor de estado para esto, pero digamos que sí lo haces.

Así que el pensamiento de la vieja escuela sería como, bueno, vamos a tener nuestra tienda global, como hablé antes, y simplemente obtendremos un proveedor de redux, lo apuntaremos al global tienda, y ya está. Así que de nuevo, se vería así. Tendrías un proveedor, le darías una tienda que acabas de crear, y luego cuando quieras usarlo, le das un selector de uso o un despacho de uso y luego puedes hablar con esa tienda. Pensamiento de la nueva escuela, ¿cómo arreglamos eso? ¿Cómo arreglamos tener esa tienda en el espacio global de esa manera? Bueno, lo que haces es que puedes crear un nuevo componente, un nuevo componente de cliente, lo llamaremos proveedor de tienda, y simplemente moveremos esa tienda allí. Ahora, para cada solicitud, tenemos esa tienda de manera única dentro de ese árbol de componentes y evitamos cualquier tipo de potencial para la contaminación cruzada de solicitudes.

Así que donde solíamos tener algo como esto, ahora vamos a tener una función llamada crear tienda que hace exactamente lo mismo, pero te devuelve una tienda de manera dinámica. Así que puedes crear una nueva para cada solicitud en ese componente de cliente, así que vamos a ver qué es eso. Así que tenemos un proveedor de tienda, bastante simple, vamos a usar un use ref para almacenar el salida de esa creación de tienda, y luego simplemente usaremos el viejo proveedor de Redux para proporcionar eso a nuestros componentes. Si tienes algún tipo de estado inicial, puedes empezar con ese use ref siendo nulo, ir a comprobar si es nulo, crear la tienda si es nulo y luego inicializar la tienda usando un despacho. Y lo bueno de eso es que si tienes estado aquí en el proveedor de la tienda, estados disociados, también está haciendo otras cosas, no sé, algo más como mostrar el menú o lo que sea, entonces puedes ejecutar esto varias veces y sólo lo hará hacer esto en el inicio inicial. Para usarlo, simplemente usamos use selector, tal como lo hicimos antes. Lo mismo. Así que a partir de ahí, es como si estuvieras usando Redux. Aquí viene, sin embargo, cuando obtienes el estado por ruta. Porque, algo específico sobre esto. Así que digamos que tenemos nuestro, esta es nuestra tienda, ¿verdad? Tenemos dos nuevos componentes allí. También queremos conducir el profundo, y las revisiones.

Entonces, tenemos, como, reseñas promedio, tenemos algunas reseñas allí arriba, y queremos que nuestra tienda impulse todo eso. Así que vamos a tener ambos conjuntos de data. Vamos a tener data del carrito que necesita estar en la parte superior del árbol, y tenemos reseñas que están un poco anidadas dentro de la página de detalles, pero aún dentro de la tienda global porque no tenemos un singleton para eso.

Entonces, cuando vamos de página en página en página, puedes ver que lo único que realmente cambia es la página de detalles. Eso es realmente agradable, desde una perspectiva de desarrollo, desde una perspectiva del cliente. Obviamente, las cosas no están cambiando, no estás obteniendo ningún parpadeo en la pantalla, ese contenido solo está cambiando. Pero eso significa que esa sección está cambiando y esa no se está actualizando. Entonces tienes un problema.

Entonces, la solución para eso es ver la fase de inicialización de cada uno de los componentes y darse cuenta de que ese componente de reseñas se está recargando, como recreado cada vez que cambias de ruta a ruta a ruta. Entonces podemos hacer una inicialización mucho más complicada pero aún bastante fácil de entender. Entonces obtienes la tienda, averiguas si estás inicializado o no, usas un usuario para eso y luego despachas las reseñas, en este caso, las reseñas iniciales que obtuviste del RSC que contiene eso. Y luego vuelves y obtienes las reseñas. Parece mucho trabajo, ciertamente más, mucho más trabajo del que hicimos con el carrito. Entonces, ¿qué podemos hacer para mejorar eso?

Entonces, una idea es usar un gestor de estado completamente diferente, un gestor de estado llamado Zustand. ¿Alguien familiarizado con Zustand? ¡Woo! ¡Okay, genial! Desearía que hubieran elegido un nombre diferente porque no soy alemán. Pero está bien. Es realmente fácil de usar. Entonces básicamente creas un hook usando create, así, bastante simple. Le das cualquier tipo de estado que quieras. Quiero decir, obviamente, tenemos un contador aquí en un incrementador, el modelo clásico de un gestor de estado. ¿Y qué tan fácil es eso? Puedes ver por qué Zustand es realmente bien amado.

Entonces, ¿cómo cambia esto el juego si usamos Zustand? Bueno, entonces tenemos nuestras reseñas. Tenemos nuestras reseñas promedio. Vamos a volver a esas partes de la página. Y para impulsarlos, porque están en diferentes partes del árbol, tal vez quieras tener un gestor de estado global, normalmente solo haríamos algo así, crearíamos user views como lo hicimos antes a nivel global. Pero no queremos hacer eso, ¿verdad?, porque sabemos la regla número uno, no globales. Entonces, ¿qué puedes hacer con eso? Bueno, podemos hacer básicamente lo mismo. Podemos elevar ese hook a un proveedor. Entonces ahora vas a tener un contexto, que va a tener el hook que usas. Entonces obtienes el contexto que a su vez te da ese hook, y luego puedes usar el hook para obtener data.

Entonces, lo que podrías haber tenido antes, de nuevo, tienes un problema aquí, tienes este useReviews que es global. En su lugar, vamos a usar un hook createReviews tal como lo hicimos antes. Y veamos cómo se usa.

El único problema aquí es que no tenemos un proveedor de Redux como lo teníamos antes. Básicamente, tenemos que recrear el proveedor de Redux. Afortunadamente, es realmente pequeño. En la parte superior, tendrías tu contexto. Básicamente dices, hey genial. El contexto contiene la salida del hook createReviews que va a ser userReviews. Vamos a tener un hook personalizado que nos dará el hook. Entonces, es un hook que devuelve un hook, un poco raro pero está bien. Y finalmente vamos a tener el proveedor. De nuevo, es un componente del cliente y porque obviamente usa hooks. Y en este caso vamos a usar useDate para mantener los data. Puedes usar useRef. Puedes usar useDate. He visto ambos métodos. Realmente no tengo una preferencia en esa lucha, así que no hay problema. Y luego le das esa tienda a nuestro proveedor recién creado y lo pasamos hacia abajo.

Ahora para inicializarlo tenemos nuestro RSC. Entonces, este es un RSC de ruta. Va a tomar un ID. Va a hacer alguna solicitud a un microservicio y luego va a usar ese proveedor de reseñas que acabamos de crear para enviar esas reseñas a los hooks y luego a los componentes.

Ahora, una cosa que es realmente importante aquí es, observa cómo estoy usando product.reviews en lugar de product. Y esto es más en general en términos de cómo usar el AppWriter. Es realmente importante mirar la salida del servidor en cada ruta para ver qué es lo que realmente está pasando porque todo lo que envíes a un componente del cliente en términos de la aplicación, se va a serializar en JS y se va a enviar por el cable. Entonces, si envías todo un producto pero en realidad no lo necesitas, estás enviando mucho más data de lo que necesitas. Así que sé muy, muy selectivo sobre los data que envías al cliente. Luego, para usarlo, simplemente obtenemos el hook de reseñas y luego usamos el hook de reseñas. Bastante fácil.

Y si quieres, simplemente haces una doble llamada como esa. Obtienes el hook de reseñas y luego usas el hook de reseñas. Ahora una cosa sobre esto, diré y siempre debería decir sobre los hooks Sushant es siempre asegúrate de, no necesito hacerlo aquí, Sushant tomará un selector como el primer argumento. Entonces te dan el estado y luego devuelves solo la pieza que necesitas. Esto es realmente importante por el bien de la eficiencia. Si no vas a usar el contexto, vas a usar un gestor de estado, por favor úsalo correctamente. Necesito todo aquí por eso es por lo que estoy haciendo eso. Pero si solo necesito reseñas, puedo darle una función que simplemente devolvería las reseñas y eso lo hará más eficiente cuando necesite actualizarme solo busco reseñas. Entonces, ¿cómo resuelve esto realmente ese problema que vimos con la versión de Redux? Entonces, con la versión Sushant podemos tener múltiples tiendas lo que lo hace mucho más fácil. Podemos tener la tienda del carrito proporcionada por el proveedor del hook del carrito que alimenta el pop-up del carrito y añade un carrito. Fácil peasy. Y luego tenemos el proveedor del hook de reseñas que alimenta solo las reseñas. Y básicamente puedes ubicarlos tan cerca como puedas del componente que los necesita. Entonces, a medida que navegas de página en página en página, la página de detalles se actualiza cada vez a medida que avanzamos. Y eso es solo en esa sección. Eso significa que este proveedor del hook de reseñas se está reestructurando completamente automáticamente y se está reconstruyendo completamente cada vez, lo que significa que no tenemos ninguno de ese código de inicialización loco. Simplemente le damos las reseñas. Fácil peasy. Así que eso es lo más fácil que he encontrado en términos de crear la tienda dentro de tu árbol de componentes y luego pasar esos datos. Entonces, regla número dos. Y esta es la que realmente me metió en problemas con el equipo de Versil, fue que los RSCs no muestran datos. De hecho, durante la presentación de esta mañana, uno de los otros presentadores hizo este punto, no muestres datos mutables básicamente dentro de tus RSCs. Entonces, ¿qué significa eso en términos prácticos? Entonces volvamos a nuestro ejemplo de Redux de nuevo porque, ya sabes, Sushant, no es como lo que todo el mundo usa. Así que tenemos esa tienda de carritos allí arriba, y tenemos nuestros RSCs. En este caso, los RSCs se muestran simplemente con una sola línea, ya sabes, el pop-up del carrito y todas las cosas del cliente son muy grandes. Así que el RSC es una página de detalles, y quiere ir a buscar la tienda del carrito. Oye, necesito saber cuántas cosas hay en el carrito. Aquí está la cosa loca, la tienda del carrito está en contexto, así que no puedes hacerlo. No puedes llegar allí desde aquí, y eso es una de las grandes cosas. Si sigues la primera regla, la segunda regla esencialmente sigue naturalmente.

No puedes acceder realmente a la tienda global porque la tienda global está en contexto. Tan fácil. Y estás como, oh, está bien, puedo sortear esto. Eso parece una limitación que puedo superar. Puedo ir y simplemente perforarla con propiedades. Claro, simplemente la crearé y la perforaré con propiedades. Pero no puedes porque la tienda se crea en el componente de diseño y luego se consume en el componente de ruta. Así que tendrías que perforar con propiedades todo el camino, y eso no va a funcionar. Así que bonita conexión entre la regla uno y la regla dos. La regla dos, simplemente se cumple por esa primera regla. Así que consigues esa architecture correcta, y funciona justo de inmediato.

Y luego la regla número tres, bastante fácil, y sigue de nuevo, separa los datos mutables e inmutables data. Así que tienes tu diseño, tienes tus RFCs. Tus RFCs están mostrando datos inmutables data como la imagen, la imagen del dragón en este caso, y el título, precio, descripción, productos relacionados. Eso son datos inmutables data que no van a cambiar en cada solicitud. No importa quién seas, va a ser el mismo número. Y luego tenemos los componentes del cliente que están mostrando datos mutables data, las cosas que realmente pueden cambiar. Así que eso es bastante sentido común, pero es bueno hablar de ello. Ahora, para averiguar todo esto, realmente creé un banco de pruebas donde vamos a ver, ¿qué puedo hacer con una aplicación que podría arruinar todo esto? Así que aquí están las cosas que comprobé. Así que creo que cuando implementas un administrador de estado en tu propia aplicación, esto es lo que creo que deberías comprobar también. Comprueba la salida SSR, asegúrate de que la salida SSR realmente muestra lo que está en la tienda, porque si no lo has inicializado correctamente, probablemente ese sea uno de los mayores lugares donde vas a encontrar que falta. Va a faltar en SSR, pero estará disponible en el cliente, y vas a tener un problema de hidratación. Comprueba los cambios de ruta. A medida que vas de ruta a ruta a ruta, estás en un spa, básicamente. Así que si no lo inicializas correctamente, vas a ver problemas allí. Así que eso es otra cosa que quieres comprobar. Y finalmente, como mencionaron algunos, el escritor de la aplicación tiene un montón de cachés. Así que bueno, cuatro, y quieres asegurarte de que compruebas la mutación y la revalidación para que estés obteniendo los datos correctos en tu tienda. Y estarás como, hombre, esto era tan fácil antes. Entonces, ¿cómo decido cuál voy a usar aquí? Así que en términos de las tecnologías subyacentes, diría que, en primer lugar, obviamente vas a usar React y Next.js, y usaría mucho las mecánicas básicas de React. Usa el estado, useReducer, useEffect. Conócelos. Estos son buenos. Una vez que entiendas el mecanismo de dependencia, realmente te facilita, hace que sea realmente fácil construir un estado que es bastante fácil de trabajar con él, y luego encima de eso, asegúrate de usar las cosas de Next.js que están incorporadas. Y de nuevo, parámetros de ruta, estado del formulario, todo eso. Si eso no funciona, si todavía tienes data que necesitas mover, poner en diferentes partes del árbol, simplemente usa el contexto básico de React. Y para eso, diría que sólo lo uses para datos de baja velocidad data. Un ejemplo sería el usuario, quién es el usuario actual, el tema, cosas así. Las cosas que no van a cambiar tan a menudo, a menos que tengas a alguien patológicamente simplemente entrando y saliendo. Algo loco. Y encima de eso, tal vez puedes arreglártelas con una biblioteca de consultas.

React Query, o SWR. Y aún no has introducido un gestor de estado pero estás construyendo una aplicación funcional que lo tiene todo. Así que esto es como, a medida que obtienes nuevas características, sigue añadiendo cosas nuevas según las necesites, pero no las traigas solo porque te gustan.

Quiero decir, me gusta React Query, pero no necesariamente lo necesitas a menos que lo necesites. Y luego finalmente, existe la opción de introducir una tienda singleton, aunque, quiero decir como mostré, hay algunos problemas con la inicialización de una tienda singleton correctamente. Así que tal vez múltiples tiendas. Tal vez usar en su lugar tiendas móviles como, o otros gestores de estado ligeros como, por ejemplo.

Si quieres aprender cómo hacer todo eso, tengo un nuevo sitio en el que estoy trabajando llamado Pro Next JS. Que tiene un tutorial completo, es gratis, 100% gratis. Puedes ir allí ahora mismo, pronextjs.dev, y tomar esta masterclass. Te enseñará todo sobre cómo hacer esto con el contexto básico de React, Redux, Sushstan, y mi nuevo gestor de estado favorito, Jotai. Que es más bien un gestor de estado atómico en el modelo de retroceso. Y luego, por supuesto, hey, siempre estoy dispuesto a recibir una suscripción. Si quieres ir a youtube.com a tu... Bueno, ahí lo tienes. Bien. Muchas gracias, señor. Muchas gracias. ¿Necesitas ayuda? Si sostienes el micrófono entonces puedo... Sí, ahí lo tienes. Vale. Entonces, ¿compartir el estado a través de estos proveedores obliga a todos los hijos a ser componentes del cliente, incluso aquellos que de otra manera habrían sido componentes del servidor? Sí. Esencialmente. Si vas a tener algún tipo de estado que se comparte a través del contexto, tiene que estar disponible. Tiene que ser un componente del cliente. Si crees que va a ser mutable, sí, asegúrate de que sea un componente del cliente. Vale. Sí. Eso no es necesariamente algo malo. Creo que hay esta percepción de que los componentes del cliente no hacen SSR, lo cual es una locura.

Ellos totalmente lo hacen. De hecho, en realidad, cuando lo piensas, solo un enrutador de páginas es esencialmente solo todos los componentes del cliente, por lo que básicamente estamos obteniendo la mejora de poder decir que componentes específicos solo se ejecutan en el servidor, y esos son RSCs, pero de lo contrario está bien, totalmente bien usar un componente del cliente.

Genial, gracias. La siguiente pregunta es de Alex. Dijiste, no hay tienda global. Quieres decir que no coloques el proveedor de la tienda dentro del diseño raíz. En su lugar, colócalo en cada diseño hijo. ¿Supongo? Estás usando un proveedor de tienda. Simplemente no lo estás especificando y no lo estás creando como una variable global. Todavía es global porque es global para cualquier contexto en el que lo coloques. Todo desde ese elemento de diseño hacia abajo o ese componente hacia abajo va a tener acceso a eso. Pero no, no va a ser global en el sentido de una variable global, que es lo que estás tratando de evitar debido a los problemas de solicitud. Vale. Gracias.

Siguiente pregunta de John. Por ahora, honestamente, Susan seguro. ¿Cuál es tu opinión? Para mí, la razón principal, quiero acceder a una tienda muda fuera de cualquier marco para no bloquear al vendedor. No estoy seguro de cuál es la pregunta. Y honestamente, solo por seguro, ¿cuál es tu opinión? Todos estos gestores de estado son geniales. No veo ningún problema con el uso, quiero decir, el bloqueo del vendedor parece extraño. No hay un verdadero vendedor aquí aparte de como Daishikato y su proyecto de código abierto. Lo bueno de Zustand y otras bibliotecas relacionadas es que realmente funcionan bien con otros hooks. Así que no es como si estuvieras quitando todo el uso del estado, no estás eliminando el uso de reduce o lo que sea. Estás usando esto en conjunto con eso. Estás diciendo, bien, esta pieza particular de data, quiero que sea global, y las otras cosas, eh, no te preocupes, no necesitan ser globales. Así que sabes, lo usas con moderación según lo necesites y luego en términos de, como puedes usar el contexto así como Zustand si ese contexto es para cosas que son de baja velocidad o van a ser el tipo de cambios que sabes que significarán una actualización de todos tus componentes de todos modos? Así que podrías ponerlo en contexto. Es muy simple. Así. Sí. Pero ¿no tienes miedo?

Entonces, voy a contarte un escenario. Mi esposa. Vale, sí. Mi esposa también es ingeniera de front end. Vale. Se unió a la empresa donde estaban usando, si no me equivoco, Redux y context. Como estás diciendo. Sí. Sí. Pero para ella fue realmente difícil de entender como recién llegada al proyecto. Sí. Qué es qué. Sí. Así que con eso en mente, si es algo más grande en lo que vas a trabajar con un equipo más grande durante varios meses o años. Sí. ¿Todavía aconsejarías mezclarlo?

Absolutamente no. Eso es lo que realmente me ha preocupado honestamente sobre Redux desde el principio, que estás metiendo muchos datos en Redux y no siempre. Quiero decir, ahora tenemos slices, así que puedes ir y dividir los datos. Pero me gusta la idea de tener árboles de componentes autónomos y la idea de tener una pieza compartida de gestión de estado que está solo dentro de ese árbol de componentes, ya sea context o si es Sushtan o si es un espacio de Jyoti, creo que es lo que se llaman. Eso para mí tiene mucho más sentido y es mucho más mantenible que tener todo en un solo lugar porque entonces, sí, no hay reglas como ¿dónde va este dato? No lo sé. ¿Se supone que debe ser local? ¿Se supone que debe ir a context? Se supone que debe ir en todos los... ¿Es la tienda global como un cubo de recogida donde pones alitas de pollo y todo lo demás de eso? Eso es definitivamente el soporte que he visto. Veo de dónde vienen las personas cuando quieren usar una tienda global donde está bien, pondré todos nuestros datos aquí y luego puedes serializar el estado y luego simplemente tenerlo donde puedes regenerar el estado y eso es genial. Simplemente no he visto eso realmente en producción mucho.

Vale. Gracias. La siguiente pregunta es ¿crees que todavía vale la pena usar un marco de React como Next.js si tienes un backend no JS, Java o .NET? Sí. Vas a estar básicamente construyendo una spa. Y creo que es un caso de uso perfectamente viable, particularmente para aplicaciones que no necesitan necesariamente SSR, ¿verdad? Y muchas aplicaciones no lo necesitan.

Si estás ejecutando un sitio de contenido, obviamente querrás tener eso. Pero si estás ejecutando algo que es una experiencia completamente personalizada como una aplicación bancaria, como que realmente no quiero tener el problema potencial de tener mi particular cuenta bancaria almacenada en caché en un CDN en algún lugar donde alguien más podría querer acceder a ella. Así que creo que las spas son muy viables y también muy portátiles. Puedes usar esa misma spa en una aplicación Electron, o algo así. Entonces puedes usar tu Java backend a través de una API. No intentaría hacer que tu Java backend realmente haga SSR. Creo que eso va a terminar mal. Pero por lo demás, sí.

Sí, podría haber sido demasiada personalización. Sí, creo que lo he visto antes, no terminó bien. Ok, suena como algo para la fiesta posterior, algunas historias de guerra. Siempre historias de guerra. Sí, me encantan esas.

Siguiente pregunta. ¿Por qué... no deberíamos usar gestores de estado? ¿Qué tienen de malo, ya que lo mencionaste como uno de tus primeros puntos? No sé nada malo de ellos, per se. Solo no sé si siempre son necesarios, dado los cambios que hemos visto en React y el poder que está incorporado en React. Supongo que lo que estaría mal con ellos son los bytes extra que estás enviando que podrías no necesitar enviar, solo porque no te gustan los arrays de dependencia o algo así. Definitivamente pienso que... tómate el tiempo, honestamente. Una de las formas en que aprendí los hooks de React fue trabajando en un proyecto donde me estaba restringido a usar nada más que los hooks base. Y eso te enseñará muy rápido cómo usar UseEddy y use effect de la manera correcta y, sí, construir y usar esas herramientas básicas de la manera correcta.

Sé que la gente viene a ver a Jack pero voy a dar mi opinión. Sí, sí, por favor, no, no, no, adelante. Lo que he visto es que la gente opta por los gestores de estado demasiado pronto. Entonces, cuando tu aplicación todavía es realmente pequeña, y digamos que estás construyendo un menú y quieres mantener el estado si está abierto o cerrado, van a optar por un gestor de estado porque aprendimos a usar Redux o lo que sea. Mientras que useState hará el trabajo perfectamente bien. Creo que usar un gestor de estado está bien, pero no optes por él inmediatamente cuando tu aplicación es super pequeña y aún no lo necesitas. Sí, totalmente.

Administro un servidor Discord. El servidor Discord tiene muchas personas y hacen preguntas generales. Una de las cosas más comunes es alguien que entra y dice, oh, tengo, sabes, una aplicación que acabo de construir que, sabes, es React más es Redux más es React Query más es esto más es eso más es eso. Y yo estoy como, ¡Whoa! Y ahora no arranca. No entiendo. Como, ok, esto no es como un, sabes, solo una cosa de puntuación donde es como solo necesito tomar cada proyecto MPM y simplemente soltarlo allí. Sabes, no, sé moderado. Y siendo juicioso al respecto, date cuenta de que estás enviando extra JavaScript al cliente por cada una de esas bibliotecas, asegúrate de que están ganando su peso, sabes, y no solo traigas cosas porque oh, sí, fulano usa React Query, por lo tanto tengo que usarlo. O sí, quiero decir, React Query es increíble.

Los routers de React y los routers de 10 segundos son impresionantes. Así que definitivamente úsalos si los necesitas. Pero no vayas y los agarres de inmediato.

Buen punto. Si lo necesitas. Si lo necesitas. Exactamente. Entonces Max pregunta, mencionaste que Next.js tiene mucho caché, algunos de ellos con algunas trampas. Ahora agregamos una tienda en la mezcla, ¿por qué usaría Next.js en lugar de simplemente React vainilla?

Bueno, esa es una buena pregunta. Quiero decir, con React vainilla, vas a tener que hacer tu propio SSR, ¿verdad? Ese es el gran valor que obtuvimos de Next.js, obtuviste un router que nos da SSR, y realmente fácilmente. Y tengo que decir, en realidad si alguna vez has intentado hacer, crear un servidor SSR, y yo lo he hecho, no es fácil hacerlo bien. Hay, ciertamente puedes obtener cosas listas para usar, puedes obtener el plugin SSR de Veet, puedes convertir una aplicación Veet en una aplicación SSR. Pero sí, si necesitas SSR definitivamente iría con algo listo para usar como Next.js o Remix es otro gran ejemplo. Y si no necesitas SSR entonces seguro, ve con probablemente Veet y React. Ciertamente no CRI.

Genial. ¿Todavía tenemos tiempo? ¿20 segundos, en serio? 5 segundos. 20 segundos. Podemos hacer esto. ¿Alguna reflexión sobre la migración de las páginas al router de la aplicación? ¿Y problemas en los que puedes encontrarte, compartir, y permanecer entre los dos? Oh, buena pregunta. Oooh. Creo que el problema de la migración se cubrió mucho esta mañana en esa masterclass. Sí, me gusta la idea de ir ruta por ruta, pero quiero decir, honestamente, el router de la aplicación es un cambio enorme. Literalmente volcaron el carro de manzanas sobre nosotros. Y realmente tienes que pensar en las cosas. No como, OK, estaba haciendo esto, ahora estoy haciendo eso. Realmente creo que tienes que dedicar el tiempo para realmente averiguar, OK, ¿por qué estoy usando el router de la aplicación para esta ruta? ¿Qué me está dando? Y en particular, creo que, cuando se trata del router de la aplicación, lo que estás buscando para aprovecharlo realmente es la renderización fuera de orden. Así que quieres esta parte de la página, puedes literalmente mirar la página y decir, OK, estamos obteniendo esta pieza de data de este microservicio en la página de detalles del producto de nuestra tienda de Dungeons and Donuts and Dragoons. Como los detalles del producto vienen de este microservicio. Vamos a bloquear esos, ya que no queremos mostrar nada hasta que tengamos la imagen y todo eso.

Pero las reseñas, eh, podrían ser un servicio lento, por lo que vamos a envolverlas en un suspense y luego vamos a hacer un renderizado fuera de orden en eso cuando esté listo. Y eso proporciona una experiencia de cliente mucho mejor, como que el cliente obtiene la página de inmediato y luego, un poco después, ven un pequeño spinner y luego obtienen algunas reseñas.

OK, genial. Y funciona con SEO. De hecho, si miras la transmisión que Googlebot va a ver, en realidad va a ver ese HTML. Pero si no tienes eso, si no tienes microservices que estén separados y que puedas usar, puedes obtener data de aquí y de allí, entonces no vas a obtener lo mejor del escritor de aplicaciones y es posible que no estés obteniendo una página tan eficiente como lo harías usando solo el router de la página. Así que es una decisión difícil.

Muy bien. Bueno, eso es todo el tiempo que tenemos. Creo que hicimos una buena prueba para Nueva York. Sí, mucho tiempo. Estoy ansioso por verte allí, sí. Muy bien. Muy bien. Denle un cálido aplauso a todos. Muy bien. Gracias. Cuídate.