Una Guía Práctica para Migrar a Componentes de Servidor

Esto es de lo que voy a hablar. Soy un consultor independiente y un colaborador de React Query, como él mencionó, y puedes encontrarme en Twitter. Realmente cambiamos eso de X después de que vi las encuestas, pero también digo Twitter. Soy FMJ.

Por lo general, el anuncio llega al final de una charla, pero como TK Dodo anunció esto antes esta semana, React Query o TAN stack query versión cinco está en vivo desde el martes. Así que lo probaremos. Así que no vamos a utilizar ninguna de estas nuevas APIs en esta charla, pero vamos a utilizar algo de la nueva sintaxis.

De acuerdo. Esto es de lo que vamos a hablar hoy. Planificación y preparación, configuración para los componentes del servidor, migración de una sola página, añadiendo diseños, y también hablaremos un poco sobre el traslado de cosas al servidor, pero no mucho. Sólo tenemos 20 minutos. Esta va a ser una charla vertiginosa. No podré cubrir todo, pero espero darles un mapa de ruta para empezar y algunos consejos útiles en el camino.

Primero, hablemos de algunos objetivos. Si tienes una aplicación existente hoy y quieres usar componentes de servidor, vas a querer abordar esto un poco diferente que si tienes una aplicación Greenfield. Queremos que esto sea, ante todo, una migración incremental, porque las migraciones de golpe nunca funcionan. Este es también un nuevo paradigma enorme para aprender, así que queremos aprender esto paso a paso, y también queremos llevar a todo el equipo con nosotros mientras lo hacemos. Tal vez la gente aquí en React Advanced ya ha leído todos los documentos, visto todas las charlas, pero tu equipo puede que no. Así que tienes que llevarlos suavemente por estas escaleras, no sólo correr hacia arriba. Y para hacer esto, vamos a mantener tanto como sea posible del modelo mental existente de tu aplicación y tu código existente. O dicho de otra manera, no trates de hacer todo a la vez. Y esto resume mi charla, supongo. Primero queremos que esto funcione, luego podemos adoptar todas estas nuevas características que estamos ansiosos por adoptar, ¿verdad? Y, de nuevo, si estás empezando en Greenfield Lab, podrías querer abrazar el futuro de inmediato.

En esta charla, vamos a usar Next y React Query. Es una especie de charla de React Query enmascarada, porque te mostraré cómo usar los componentes del servidor con React Query, pero ese no es el punto principal de la misma. Se centrará un poco en la obtención de datos, aunque, y la razón de eso es esta. Muchos ejemplos y guías de migración que existen hoy tienen algo como esto. Estás haciendo una búsqueda en un componente del servidor. Estás añadiendo alguna configuración. Y eso es todo.

Si estás construyendo una aplicación web compleja hoy en día, también tienes que lidiar con mutaciones e invalidaciones de data, y ahora mismo, antes de los componentes del servidor, solo hay una forma de hacerlo, ¿verdad?, y eso es en el cliente. Así que quiero hablar un poco sobre cómo hacer esto si estás utilizando una biblioteca de terceros para gestionar tu data hoy en día. Eso no tiene por qué ser React Query, por supuesto.

Otra cosa es que los documentos de Next actualmente enumeran cuatro formas de obtener data en los componentes del servidor o al usar componentes del servidor. Y quiero afirmar que hay una quinta forma, que es la forma en que muchos de nosotros podríamos estar haciéndolo hoy en día, que es precargar data en el servidor, pero hacer todas las invalidaciones y reobtenciones y cosas en el cliente. Posiblemente con bibliotecas de terceros. Vale. El enfoque que vamos a tomar es utilizar los componentes del servidor principalmente como cargadores de data y no renderizar tanto en ellos. Mantén el resto de la aplicación como componentes del cliente, y vamos a seguir utilizando React Query. También vamos a seguir utilizando tu lógica de caché existente en tu aplicación. Porque ya tienes una caché que funciona, y la caché es difícil de hacer bien, ¿verdad? Y el enrutador de la aplicación tiene cuatro. Cuatro cachés que interactúan entre sí. Y estas son súper poderosas. Son geniales, y querrás optar por ellas más tarde después de que tu migración esté terminada.

Entonces, para hacer eso, intentaremos imitar el comportamiento existente que probablemente tengas con get server side props o get static props, y la forma en que lo haremos es exportando esta configuración, force dynamic o force error, y entraremos en eso. Pero primero necesitamos planificar y prepararnos para esta migración. Y lo primero que quieres hacer es leer toda la documentation. Tómate un café o un té o algo así, pasa una tarde con estos documentos, los documentos de React, especialmente la guía de migración de Next y el resto de los documentos de Next, son realmente, realmente buenos, muy completos, y también cualquier documentation de bibliotecas de terceros.

Luego quieres inventariar tus utilidades y tu código compartido, pensar si hay algo que necesites hacer allí para soportar el enrutador de la aplicación. Quieres inventariar tus bibliotecas de terceros. ¿Realmente soportan el enrutador de la aplicación? ¿Qué vas a hacer si no lo hacen? Quieres pensar en el despliegue, DevOps, pruebas, authentication, pero no tienes que resolver todas estas cosas ahora, pero es muy bueno tener una idea del alcance y anticipar cualquier obstáculo que puedas tener para tu aplicación. ¿Dónde va a ser complicado para ti? Así que las páginas y el enrutador de la aplicación son en cierto sentido dos frameworks separados. Tienen sus propios paquetes y navegar entre ellos es una recarga completa de la página. Así que eso probablemente esté bien para muchas de tus páginas, pero para algunas puede que no lo esté. Si tienes una página de categoría y una página de detalles de producto entre las que navegas muy a menudo o algo así. Así que traza qué páginas crees que vas a necesitar migrar juntas. Luego quieres elegir una primera ruta básica para migrar. Probablemente sea la página de tu empresa, ¿verdad? Si me atrevo a adivinar. Y luego eliges una segunda ruta más compleja para migrar.

Y lo primero que quieres hacer es envolver esos componentes en modo estricto. Este componente te va a dar un montón de errores para corregir. O advertencias, al menos. Y la razón por la que quieres hacer esto primero es que el enrutador de la aplicación en realidad utiliza características concurrentes por defecto. Así que cuando haces transiciones de página, navegaciones de página, eso es una transición concurrente en el enrutador de la aplicación. Así que, este es el momento en que todos esos errores que tienes en tus efectos de uso y todo eso van a mostrarse.

En cierto sentido, podrías decir que esta es la verdadera actualización de React 18. Cuando hayas terminado con eso, puedes desplegarlo en tu enrutador de páginas existente. Probablemente habrás corregido algunos errores en el camino. Y luego puedes aumentar tus versiones. Puedes hacer eso antes, en realidad, Next y React y las bibliotecas de terceros que tienes. Quieres ocuparte de algunas cosas específicas de Next. Puedes leer sobre estas en la documentación. Son realmente buenas. Pero el único punto que quiero hacer es que puedes usar todas estas en el enrutador de páginas también. Así que puedes ocuparte de todo esto y desplegarlo en tu aplicación existente.

Y luego es el momento de configurar el enrutador de la aplicación, migrar tu primera página, añadir Todos estamos cansados de esta presentación ahora. Así que hagamos una demostración, en su lugar. Vamos a mover aquí. A ver si funciona. Oh, ese es el horario. Genial. Vale.

Así que esta es una página de elaboración casera de cerveza. Como has oído, yo mismo soy un cervecero casero. Así que he seleccionado algunos ingredientes británicos clásicos para elaborar cerveza británica. También estamos vendiendo algunos barriles aquí en los tamaños Firkin y Hogshead. ¿Qué te pasa? También tenemos nuestra página estándar de la empresa, y esta es la página que vamos a migrar. Tiene algunas data de búsqueda para esta línea de tiempo y estas ofertas de trabajo. Quiero ser el jefe de Lúpulos. Ese es mi objetivo. Esta página también tiene, como, tu página 404 personalizada. Y empezaremos por migrar eso.

Así que lo primero que haremos es añadir una carpeta de aplicación aquí. Y también queremos reiniciar el servidor de desarrollo. Pero tan pronto como lo hagamos y recarguemos esta página, te darás cuenta de que ya no tenemos nuestro 404 página 404 personalizada. Tan pronto como esta carpeta de aplicación incluso existe, esto deja de funcionar. Así que lo arrastraré aquí. Queremos hacer esto en este caso un componente del cliente. Porque este componente de error lo requiere. Y también queremos renombrar esto a no encontrado. Ahora, hay un error en el React Server Components bundler. Pero si reiniciamos, va a funcionar bien. Así que tendremos nuestra página 404 personalizada de vuelta. Y esto está funcionando actualmente porque ya he añadido un diseño de raíz aquí. Es uno muy básico con solo HTML y etiquetas de cuerpo.

Así que migraremos todo lo que necesitemos del enrutador de páginas a continuación. El diseño raíz es una combinación de los componentes del documento y de la aplicación en el enrutador de páginas. No tenemos nada que migrar del documento. Tú podrías tenerlo. Pero este componente de la aplicación sí tiene algunas cosas que queremos migrar. Tenemos aquí algunos proveedores que veremos a continuación. Tenemos algunos metadatos, tenemos algo de CSS global. Y queremos mover todo eso. Pero empecemos con los proveedores. Este componente de proveedores está configurando React Query con un cliente de consulta y un proveedor de cliente de consulta. Tiene algún otro proveedor muy complejo. No sé qué hace eso. Y lo primero que queremos hacer es simplemente añadir use client en la parte superior de esto. Esto está utilizando un montón de características que sólo puedes tener en componentes de cliente. Así que tiene sentido hacer eso. A continuación iremos al diseño y envolveremos esto en el componente de proveedores. Y lo bueno de esto ahora es que si cambias estos proveedores, se van a aplicar tanto a las páginas como al enrutador de la aplicación. Así que se mantiene sincronizado. También tenemos algunos metadatos que queremos incluir. Ahora podemos exportar eso como un campo de metadatos. Esto está tipado, lo cual es agradable. Así que puedes captar cualquier error de escritura. Y queremos añadir también este CSS global. La última cosa que ya he hecho es que quieres añadir estos componentes de error también. El error global necesita incluir su propio diseño de ruta porque eso captura errores en el diseño de ruta, y este otro componente de error también quieres incluirlo. Estos están detallados muy bien en los siguientes documentos, así que puedes ir a leerlos.

Oh, lo siento por dejarte mirar esa página 404 durante unos minutos. A continuación, vamos a mover esta página de la empresa. Así que lo que queremos empezar a hacer es ver cómo se ve esto hoy. Y comencemos con el GetServerSideProps que tenemos aquí. En este GetServerSideProps, actualmente estamos creando un cliente de consulta. Estamos prebuscando un montón de data que necesitamos, pie de página de navegación, línea de tiempo y ofertas de trabajo. Estamos deshidratando esos data al cliente y poniéndolos en un límite de hidratación. Esto se llamaba hidratar en V4 pero ahora es límite de hidratación. Y esto es lo que hace que esos data estén disponibles en el cliente o durante el paso de SSR por así decirlo. Entonces, GetServerSideProps está prebuscando y esto lo está haciendo disponible. Y luego tenemos este componente con navegación, sección de la empresa y pie de página. Esta sección de la empresa, es el componente que realmente utiliza useQuery para leer las ofertas de trabajo y los data de la línea de tiempo. Y el pie de página de navegación está haciendo lo mismo. Así que, comencemos moviendo esto al enrutador de la aplicación y lo renombraremos como empresa. Voy a mantener esto como un componente del cliente. Así que, queremos seguir adelante y añadir useClient en la parte superior aquí. Pero voy a mover el resto de esto a un componente del servidor. Esta es la parte de prebúsqueda. Así que, he configurado algunas importaciones aquí para ahorrarnos algo de tiempo. Pegaremos esto. Moveremos toda esta obtención de data al componente en su lugar, que ahora podemos hacer asíncrono porque este es un componente del servidor. Quitaremos esto. Realmente necesitamos quitar eso. Ya no viene de las propiedades. Realmente no necesitamos las propiedades aquí. Vamos a quitar eso. Y lo último que queremos hacer es exportar esta opción de configuración, dynamic force dynamic, para imitar el comportamiento de caché de getServerSideProps. Así que, siempre se revalida tan pronto como se solicita esta página. Y en mi caso, también quiero recordar renombrar esto a página. Así que, cuando recargamos esta página, todo funciona.

Las demos de migración son probablemente las más aburridas porque siempre parecen iguales después. ¿Cómo sabemos incluso que esto está utilizando el enrutador de la aplicación, verdad? Realmente tenemos que entrar en la consola aquí y tal vez revisar la red y recargar para ver que esto está utilizando las características del enrutador de la aplicación.

Y si hacemos clic para volver a la página principal, veremos que esto es una recarga completa de la página, pero es muy rápida, por lo que no lo notarás a menos que realmente mires las DevTools. Y si volvemos a la página de la empresa, es una recarga completa de la página de nuevo. Vale. Genial.

Pero esto parece un poco raro. ¿Por qué tenemos que tener la navegación y el pie de página dentro del componente de la empresa aquí? Queremos mover eso a un diseño compartido, el paso cuatro de esta presentación. Así que simplemente voy a eliminar esto. Podríamos eliminar este componente completo ahora, pero lo mantendré por cuestión de tiempo. También parece que no tiene sentido que estemos precargando el pie de página y vaya, el pie de página y los datos de navegación en la página de la empresa. Así que también voy a eliminar eso. Si esto juega bien.

Y el lugar que parece tener sentido para tener este diseño de navegación está en la raíz del diseño para esta página. Así que podemos empezar por agarrar esto. Que es exactamente lo que acabamos de eliminar. Precargando los datos de navegación y pie de página y estas consultas. Y podemos agarrar esto. Y el secreto aquí es que puedes usar múltiples límites de hidratación. Así que este diseño de raíz está utilizando un límite de hidratación para hidratar todas las consultas necesarias para el diseño de raíz. Y la página está utilizando otro límite de hidratación para hidratar todos los datos de la página de la empresa. Y puedes usar cuantos quieras. Si tienes rutas paralelas, etc. Puedes precargar datos dondequiera que tengas un componente de servidor. Vale. Y ahora la navegación y el pie de página están de vuelta, como puedes ver. El último punto en esta demo es que no estamos usando suspense aquí. Esto es solo la API de consulta de uso regular.

Lo que significa que esta página no está transmitiendo SSR. Es solo lo regular, como, aquí está tu HTML, ¿verdad? Tan pronto como agregas un límite de suspense, si tienes una aplicación que usa suspense ahora que estás migrando, tan pronto como agregues eso, esto opta por la transmisión cuando estás utilizando el enrutador de la aplicación. Entonces, si estás implementando en Vercel, eso va a funcionar de inmediato, pero si estás haciendo una implementación personalizada, vas a querer verificar que soporta la transmisión, verificar tu CDM, que soporta la transmisión, que está configurado para ello, etc. Si no estás usando suspense hoy, no hay necesidad de agregar suspense como parte del viaje de migración. Esto funciona bien sin él. Pero lo interesante es que incluso si no estamos usando las APIs de suspense de react query aquí, podemos de hecho agregar un límite de suspense de todos modos. Porque el componente del servidor es suspenseful. Así que ahora la navegación data es realmente rápida, pero la data de la empresa es lenta. Así que cuando recargamos la página, podemos obtener la navegación inmediatamente y tener un spinner para el resto. Incluso si la biblioteca de terceros en este caso no está haciendo el trabajo pesado de suspense por así decirlo.

Bien. Volvamos a las diapositivas. Cuando hayas migrado tu primera página y quieras desplegarla en producción, busca cualquier error, Luego puedes seguir agregando más páginas, agregando más diseños, estructurando tu aplicación. Y en algún momento vas a sentir la necesidad de no hacer más trabajo de migración y empezar a mover cosas al servidor.

Y mi consejo aquí es comenzar de manera simple y buscar las victorias rápidas. Esta página de la empresa probablemente no necesita React Query, ¿verdad? Puedes eliminar eso bastante rápido y hacer que toda la página sea solo un componente de servidor y mover ese límite de uso del cliente hacia abajo o simplemente eliminarlo por completo. Y entonces no tienes que enviar todo ese JavaScript al cliente.

Entonces, cuando empieces a migrar cosas a componentes de servidor, tengo un consejo muy importante. Supongamos que estamos migrando este componente de navegación y especialmente este carrito de compras. Y entonces podría ser tentador hacer algo como esto si estás usando React Query. Estás obteniendo una consulta. Y estás deshidratando los datos al cliente como lo hacías antes. Pero también estás pasando los artículos del carrito aquí al artículo del carrito. ¿Y por qué es esto malo? Bueno, si estás usando React Query aquí, probablemente también lo estás usando para mutar ese carrito. Estás agregando artículos al carrito. Y cuando estás haciendo eso, probablemente estás invalidando esta consulta en los componentes del cliente. Pero eso no hace que el componente del servidor se vuelva a renderizar. Así que el carrito items.length va a permanecer en 0 en el componente del servidor mientras se están agregando artículos al carrito.

Entonces aquí está mi consejo. No renderices datos dinámicos en componentes de servidor si estás usando bibliotecas de terceros al menos. Si estás optando por el nuevo paradigma de NextJS, esto va a funcionar. Validará de nuevo el componente del servidor. Pero eso es solo un paso posterior si estamos hablando del viaje de migración. Así que mientras estás migrando, usa tantos componentes del cliente como quieras o necesites, porque no hay nada malo con ellos, especialmente cuando estás migrando. Otra forma de decir esto es no mezcles la propiedad de datos entre los componentes del servidor y del cliente. Así que algunas conclusiones. Prepárate paso a paso. Intenta mantener tanto de tu modelo mental existente como sea posible. Evita cualquier complejidad que puedas al principio, como las cachés. Y para imitar lo que probablemente estás haciendo hoy si estás construyendo una aplicación web compleja, precarga datos en componentes de servidor, pero deja que los componentes del cliente manejen el resto del ciclo de vida de los datos.

Y esto debería ser aplicable ya sea que estés usando React Query u otra biblioteca. Pero lee sus documentación, por supuesto. Si quieres aprender más, Lance tiene una charla donde habla más sobre suspense y streaming. Y Jack tiene una gran charla donde profundiza más en la gestión de estado y los componentes del servidor en general. Y esa charla de Jack será al inicio de la transmisión, si te unes a nosotros de forma remota. Y la charla de Lance será un poco más tarde en el día para aquellos que se unen a nosotros a través de la transmisión.

Gracias. Realmente disfruté esta charla. De hecho, mientras hablabas, ya decidí algunas cosas que quiero cambiar y probar en la aplicación de NextJS que he estado construyendo. Así que, probablemente voy a buscar mi laptop en el descanso y ver si puedo jugar un poco con eso. Debería estar bien. Debería estar bien. Muy bien. Vamos a saltar directamente a la primera pregunta, que es de Dennis. Dice, están perdiendo el por qué, ¿verdad? ¿Por qué querríamos migrar los componentes del lado del servidor? ¿Tienes algunos casos de uso? Sé que Mark también habló de esto antes. ¿Pero quieres dar tu propia opinión también? Me encanta esa pregunta. Fue una de las diapositivas que tuve que cortar cuatro veces. Y puedo hablar un poco sobre eso también. Bueno, eso depende de tu aplicación, ¿verdad? Entonces, no todas las aplicaciones podrían ganar tanto al usar componentes del servidor. Así que, esta charla espera que ya hayas descubierto eso y decidido que sí quieres migrar. Pero hay algunas buenas razones para muchas aplicaciones. Como esta página de la empresa. ¿Por qué estamos enviando tanto JavaScript para renderizar esa página de la empresa de nuevo en el cliente, ¿verdad? Cuando podríamos tener eso como contenido mayormente estático. También podría haber otras características que quieras implementar más adelante donde todas estas cuatro cachés en el enrutador de la aplicación, por ejemplo, son realmente poderosas donde puedes invalidar datos desde el cliente que invalida los componentos del servidor también. Pero no solo para este usuario. Para todos los usuarios. Y hay otra cosa de la que no hemos hablado mucho en el ecosistema. El enrutador de la aplicación en sí, si estamos hablando específicamente de Next, es fantástico. Hay muchas otras características fantásticas, como el enrutamiento anidado, como todas esas cosas. Incluso si solo usas componentes del servidor como las nuevas props del lado del servidor o props estáticas ahora podemos tener eso en muchos lugares y precargar los datos más cerca de donde los estás usando.

Si básicamente no estás renderizando nada en el componente del servidor. Así que también está eso. Pero en última instancia depende de tu aplicación y si ves algún beneficio de este nuevo paradigma. La primera de muchas respuestas, depende, para hoy.

Pasemos a la siguiente pregunta, que es sobre autenticación. Especialmente cuando hablaste de tener también APIs de terceros. Si tienes una API detrás de tu authentication, ¿cómo la manejas tanto para el cliente como para el servidor? Esa es una gran pregunta. Y no es una con la que esté muy familiarizado. He construido algo de autenticación con una biblioteca de terceros para componentes del servidor. Y diría que todavía es un poco inestable, esas APIs. Como, tienes que considerar estos componentes del servidor en sí mismos. Esos son como una API. Puedes acceder a data en ellos. Tienes que considerar tus APIs reales, de las cuales no hablé en la charla. Teníamos una carpeta de páginas/API, y eso puedes mantenerlo en páginas. Eso seguirá funcionando. Así que tendrás que mantener tu autenticación allí. Y mantener la autenticación en el cliente también. Así que realmente no tengo una gran respuesta para eso. Bueno, esa es una respuesta que puede ser otra charla la próxima vez. Así que tal vez alguien debería hacer una investigación y dar una charla en React Advance para el próximo año.

Hablando de RSEs, todavía son una característica experimental, pero en tu opinión, ¿son seguros para usar en aplicaciones de producción? Esa es una pregunta difícil. Creo que sí lo son. Como si me hubieras preguntado hace un par de meses, creo que esta historia era bastante inestable. Como viste, todavía había un Bundler de Componentes del Servidor que apareció, pero eso, para, esto solo aparece para ese 404 específicamente. Como todavía hay errores. Han corregido la mayoría de los esenciales, como Alvar que está sentado allí. Gracias por la ayuda con la charla, por cierto. Se ha reportado, no sé cuántos, y creo que la mayoría de ellos están corregidos. Así que sí, pero lo clave es probarlo a fondo, no solo porque puede que haya errores en la parte de los Componentes del Servidor, sino porque este es un nuevo paradigma.

Y cuando estás migrando tu código, también puede haber errores. Así que diría que es estable, pero pruébalo a fondo. Ahora seguro. No creo que sea clásico, ¿verdad? Con las características experimentales, se vuelven convencionales antes de que realmente salgan de la fase experimental cada vez más. Así que definitivamente otra pregunta del tipo depende. Y hagamos solo una más también, solo por tiempo, pero siempre puedes venir y tener más respuestas con él en la sesión de preguntas y respuestas del orador.

Si nos estamos moviendo a Componentes del Servidor, estamos poniendo más carga en el servidor y aumentando el costo de ejecutar el servidor. Y esto de nuevo vino con Mark. ¿Es eso algo que realmente queremos hacer? ¿Es eso algo que vale la pena hacer? ¿Y tal vez cuáles son algunos factores que considerarías al tomar esa decisión? Eso es bueno. Depende, ¿verdad? Número dos. Pero lo hace. Por supuesto, va a costar más si hacemos más trabajo en los servidores, pero eso también va a proporcionar una mejor user experience para los usuarios, porque un servidor es bastante más potente que esto, ¿verdad? Así que depende de tu aplicación. Aunque diría que también tiene la oportunidad de reducir la carga en los servidores, porque estás siendo más eficiente, especialmente si optas por estas cachés, que son granulares, puedes almacenar en caché diferentes partes de la página. Si tienes una parte de la página que es estática, puedes almacenarla en caché para siempre, mientras que el resto es dinámico, lo que podría reducir la carga. Y todas estas llamadas a la API que estamos haciendo, que probablemente son una de las cosas más costosas, las tenemos de todos modos. Así que solo hacer la parte de renderizado del servidor, componentes del servidor, seguro, eso va a añadir carga. Y especialmente si haces componentes del servidor para toda tu aplicación. Pero creo que definitivamente tiene sentido. Creo que en el ecosystem, necesitamos más renderizado del servidor y no menos. Sí. Quiero decir, tiene que ir a algún lugar. Y supongo que tu decisión a tomar es si quieres que esté en el servidor donde no necesariamente afecta a la user experience o quieres poner eso en el cliente? Pero una vez más, Frederic, muchas gracias. Démosle una ronda más de aplausos. Lo hago. Gracias.