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

This ad is not shown to multipass and full ticket holders
React Summit US
React Summit US 2025
November 18 - 21, 2025
New York, US & Online
The biggest React conference in the US
Learn More
In partnership with Focus Reactive
Upcoming event
React Summit US 2025
React Summit US 2025
November 18 - 21, 2025. New York, US & Online
Learn more
Bookmark
Rate this content

Los Componentes de Servidor son la nueva gran cosa, pero hasta ahora gran parte del discurso a su alrededor ha sido abstracto. Cambiemos eso. Esta charla se centrará en el lado práctico de las cosas, proporcionando un mapa de ruta para navegar el viaje de migración. Comenzando desde una aplicación que utiliza el antiguo enrutador de páginas de Next.js y React Query, desglosaremos este viaje en un conjunto de pasos accionables e incrementales, deteniéndonos solo cuando tengamos algo que se pueda enviar y que sea claramente superior a lo que comenzamos. También discutiremos los próximos pasos y estrategias para adoptar gradualmente más aspectos de este paradigma transformador.

This talk has been presented at React Advanced 2023, check out the latest edition of this React Conference.

FAQ

React Query es una biblioteca que facilita la gestión de estados y la sincronización de datos en aplicaciones React. En la charla, se muestra cómo usar React Query con componentes del servidor para manejar la obtención de datos, aunque el principal enfoque no es React Query en sí, sino la integración de este con los componentes del servidor para optimizar la carga y manejo de datos.

Una migración incremental significa actualizar o migrar una aplicación web poco a poco en lugar de hacerlo de golpe. Esto permite solucionar problemas específicos paso a paso y asegura que cada parte de la aplicación sigue funcionando correctamente antes de proceder a la siguiente, reduciendo el riesgo de errores masivos.

Antes de los componentes del servidor, las mutaciones e invalidaciones de datos generalmente se manejan en el cliente. Sin embargo, con los avances en tecnologías de servidor, es posible precargar datos en el servidor y luego manejar las invalidaciones y reobtenciones en el cliente, utilizando posiblemente bibliotecas de terceros como React Query.

Al planificar una migración a componentes del servidor, es crucial leer toda la documentación relevante, inventariar utilidades y código compartido, verificar la compatibilidad de las bibliotecas de terceros, y anticipar obstáculos en áreas como el despliegue, pruebas y autenticación. Esto ayuda a preparar mejor el entorno y el equipo para la transición.

Es recomendable llevar al equipo paso a paso a través del proceso de aprendizaje, manteniendo tanto como sea posible del modelo mental existente de la aplicación y el código. No se debe intentar adoptar todas las nuevas características de una sola vez, sino más bien enfocarse en hacer que el sistema funcione primero antes de adoptar nuevas funcionalidades.

Mover más carga al servidor a través de componentes del servidor puede aumentar los costos operativos, pero también puede mejorar la experiencia del usuario al hacer la aplicación más eficiente y rápida. La decisión de usar más renderizado del servidor debe equilibrar estos factores, considerando qué es más beneficiario para la aplicación y la experiencia del usuario.

Fredrik Höglund
Fredrik Höglund
28 min
20 Oct, 2023

Comments

Sign in or register to post your comment.
Video Summary and Transcription
La versión cinco de React Query está en vivo y estaremos discutiendo el proceso de migración a componentes de servidor utilizando Next.js y React Query. El proceso implica planificar, preparar y configurar componentes de servidor, migrar páginas, agregar diseños y mover componentes al servidor. También exploraremos los beneficios de los componentes de servidor, como reducir el envío de JavaScript, habilitar un potente almacenamiento en caché y aprovechar las características del enrutador de la aplicación. Además, cubriremos temas como el manejo de la autenticación, la representación en componentes de servidor y el impacto en la carga y los costos del servidor.

1. Introducción a los Componentes del Servidor

Short description:

Soy un consultor independiente y un colaborador de React Query. La versión cinco de React Query o TAN stack query está en vivo desde el martes. Hablaremos sobre la planificación y preparación, la configuración de los componentes del servidor, la migración de una sola página, la adición de diseños y el traslado de cosas al servidor. Nuestro objetivo es abordar el uso de los componentes del servidor como una migración incremental y llevar a todo el equipo con nosotros. Usaremos Next y React Query para demostrar el proceso.

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.

2. Planificación y Preparación para la Migración

Short description:

Si estás construyendo una aplicación web compleja hoy en día, también tienes que lidiar con mutaciones e invalidaciones de datos. El enfoque que vamos a tomar es utilizar los componentes del servidor principalmente como cargadores de datos y no renderizar tanto en ellos. También vamos a seguir utilizando React Query y tu lógica de caché existente. Para prepararte para esta migración, lee toda la documentación, inventaría tus utilidades y bibliotecas de terceros, y piensa en el despliegue, DevOps, pruebas y autenticación. Traza qué páginas crees que vas a necesitar migrar juntas y elige una primera ruta básica para migrar. Luego envuelve esas en modo estricto.

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.

3. Configuración de Componentes del Servidor

Short description:

El primer paso es envolver tus componentes en modo estricto para identificar y corregir cualquier error o advertencia. Esto es crucial porque el enrutador de la aplicación utiliza características concurrentes por defecto, revelando errores en los efectos de uso y otras áreas. Una vez que hayas resuelto estos problemas, despliega en tu enrutador de páginas existente y actualiza tus versiones. Las consideraciones específicas de Next se pueden encontrar en la documentación. Recuerda, también puedes utilizar estas características en el enrutador de páginas.

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.

4. Configuración del Enrutador de la Aplicación y Migración de la Primera Página

Short description:

Y luego es el momento de configurar el enrutador de la aplicación, migrar tu primera página, agregar una demostración, pasar a una página de elaboración casera de cerveza y migrar la página 404 personalizada. Para empezar, añade una carpeta de aplicación y reinicia el servidor de desarrollo. Arrastra la carpeta de la aplicación a la ubicación deseada y conviértela en un componente del cliente. Renombra el componente de error a 'no encontrado'. Reinicia el servidor para solucionar un error en el empaquetador de Componentes del Servidor de React. Ahora, la página 404 personalizada está funcionando con el diseño básico de la raíz.

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.

5. Migrando Componentes del Enrutador de Páginas

Short description:

Migraremos los componentes necesarios del enrutador de páginas. El componente de la aplicación tiene proveedores para React Query y otros proveedores complejos. Añadiremos 'use client' al componente de proveedores y lo envolveremos en el diseño. Esto mantiene los proveedores sincronizados tanto para las páginas como para el enrutador de la aplicación. También incluiremos metadatos y CSS global. Además, añadiremos los componentes de error, cada uno con su propio diseño de ruta. Consulta la documentación de Next.js para obtener más detalles.

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.

6. Trasladando la Página de la Empresa al Enrutador de la Aplicación

Short description:

Vamos a mover la página de la empresa al enrutador de la aplicación. Comenzaremos con GetServerSideProps, donde prebuscamos datos y los deshidratamos. Los componentes de la sección de la empresa y del pie de página de navegación utilizan useQuery para leer las ofertas de trabajo y los datos de la línea de tiempo. Moveremos la obtención de datos al componente y la haremos asíncrona. La exportación de la opción de configuración dynamic force dynamic asegura la revalidación en cada solicitud de página.

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.

7. Demos de Migración y Cambios de Diseño

Short description:

Las demos de migración siempre parecen iguales después. Necesitamos revisar la red y recargar para ver las características del enrutador de la aplicación. Al hacer clic para volver a la página principal se activa una recarga rápida de la página completa. Volver a la página de la empresa también activa una recarga completa de la página. Queremos mover la navegación y el pie de página a un diseño compartido. La precarga de los datos de navegación y pie de página en la página de la empresa no tiene sentido. Podemos usar múltiples límites de hidratación para precargar datos. Agregar un límite de suspense permite la transmisión con el enrutador de la aplicación.

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.

8. Streaming SSR con Límite de Suspense

Short description:

Agregar un límite de suspense al enrutador de la aplicación permite el streaming SSR. Funciona de inmediato en Vercel, pero las implementaciones personalizadas deben ser revisadas para soporte de streaming. Si no se utiliza suspense, no es necesario para la migración. Sin embargo, agregar un límite de suspense aún puede mejorar el rendimiento al permitir la recuperación rápida de datos de navegación.

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.

9. Migrando a Componentes de Servidor

Short description:

Al migrar a componentes de servidor, comienza de manera simple y busca victorias rápidas. Elimina el uso innecesario de React Query de los componentes del servidor para reducir JavaScript del lado del cliente. Evita renderizar datos dinámicos en componentes de servidor cuando uses bibliotecas de terceros. Utiliza componentes del cliente durante la migración para evitar mezclar la propiedad de datos entre los componentes del servidor y del cliente. Prepárate paso a paso y evita la complejidad innecesaria, como las cachés. Precarga datos en componentes de servidor y deja que los componentes del cliente manejen el resto del ciclo de vida de los datos.

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.

QnA

Razones para Migrar Componentes del Lado del Servidor

Short description:

Esto debería ser aplicable ya sea que estés usando React Query u otra biblioteca. Lance tiene una charla sobre suspense y streaming, mientras que Jack cubre la gestión de estado y los componentes del servidor. La primera pregunta es sobre las razones para migrar los componentes del lado del servidor. No todas las aplicaciones pueden beneficiarse de ello, pero para muchas, puede reducir el envío de JavaScript, habilitar un potente almacenamiento en caché y aprovechar las fantásticas características del enrutador de la aplicación, como el enrutamiento anidado. Los componentes del servidor se pueden usar en varios lugares y precargar datos más cerca de donde se necesitan.

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.

Renderizado en Componentes del Servidor y Manejo de Autenticación

Short description:

Si básicamente no estás renderizando nada en el componente del servidor, depende en última instancia de tu aplicación y si ves algún beneficio de este nuevo paradigma. Pasemos a la siguiente pregunta sobre autenticación y manejo de APIs de terceros tanto para el cliente como para el servidor. Es un tema complejo y no tengo una respuesta definitiva. Los RSEs todavía son experimentales, pero pueden ser utilizados en aplicaciones de producción. Aún hay algunos errores, pero en su mayoría han sido corregidos. Es importante probar a fondo los RSEs porque representan un nuevo paradigma.

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.

Migrando Código y Carga del Servidor

Short description:

Al migrar código, espera errores, pero es estable. Las características experimentales se vuelven convencionales. Pasar a Componentes del Servidor aumenta la carga del servidor y los costos, pero mejora la experiencia del usuario. El almacenamiento en caché y el renderizado eficiente pueden reducir la carga. El renderizado del servidor es beneficioso para el ecosistema. Decisión: el renderizado del servidor o del cliente depende de la experiencia del usuario. ¡Gracias, Frederic!

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.

Check out more articles and videos

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

Simplificando los Componentes del Servidor
React Advanced 2023React Advanced 2023
27 min
Simplificando los Componentes del Servidor
Top Content
React server components simplify server-side rendering and provide a mental model of components as pure functions. Using React as a library for server components allows for building a basic RSC server and connecting it to an SSR server. RSC responses are serialized virtual DOM that offload code from the client and handle interactivity. The client manifest maps serialized placeholders to real components on the client, enabling dynamic rendering. Server components combine the best of classic web development and progressive enhancement, offering the advantage of moving logic from the client to the server.
Una Guía del Comportamiento de Renderizado de React
React Advanced 2022React Advanced 2022
25 min
Una Guía del Comportamiento de Renderizado de React
Top Content
This transcription provides a brief guide to React rendering behavior. It explains the process of rendering, comparing new and old elements, and the importance of pure rendering without side effects. It also covers topics such as batching and double rendering, optimizing rendering and using context and Redux in React. Overall, it offers valuable insights for developers looking to understand and optimize React rendering.
Construyendo Mejores Sitios Web con Remix
React Summit Remote Edition 2021React Summit Remote Edition 2021
33 min
Construyendo Mejores Sitios Web con Remix
Top Content
Remix is a web framework built on React Router that focuses on web fundamentals, accessibility, performance, and flexibility. It delivers real HTML and SEO benefits, and allows for automatic updating of meta tags and styles. It provides features like login functionality, session management, and error handling. Remix is a server-rendered framework that can enhance sites with JavaScript but doesn't require it for basic functionality. It aims to create quality HTML-driven documents and is flexible for use with different web technologies and stacks.
Compilador React Forget - Entendiendo React Idiomático
React Advanced 2023React Advanced 2023
33 min
Compilador React Forget - Entendiendo React Idiomático
Top Content
Joe Savona
Mofei Zhang
2 authors
The Talk discusses React Forget, a compiler built at Meta that aims to optimize client-side React development. It explores the use of memoization to improve performance and the vision of Forget to automatically determine dependencies at build time. Forget is named with an F-word pun and has the potential to optimize server builds and enable dead code elimination. The team plans to make Forget open-source and is focused on ensuring its quality before release.
Uso efectivo de useEffect
React Advanced 2022React Advanced 2022
30 min
Uso efectivo de useEffect
Top Content
Today's Talk explores the use of the useEffect hook in React development, covering topics such as fetching data, handling race conditions and cleanup, and optimizing performance. It also discusses the correct use of useEffect in React 18, the distinction between Activity Effects and Action Effects, and the potential misuse of useEffect. The Talk highlights the benefits of using useQuery or SWR for data fetching, the problems with using useEffect for initializing global singletons, and the use of state machines for handling effects. The speaker also recommends exploring the beta React docs and using tools like the stately.ai editor for visualizing state machines.
React Query API Design – Lecciones Aprendidas
React Advanced 2024React Advanced 2024
26 min
React Query API Design – Lecciones Aprendidas
Top Content
I'm super excited to be here today, giving my first live talk at an in-person conference. Dominik, the maintainer of React Query, walks through the API design decisions, including success stories, trade-offs, and mistakes. Tener Linsley designed React Query's medium-sized query API to be minimal, intuitive, powerful, and flexible. Major versions in open source require marketing efforts, but not primarily for adding new features. TypeScript is crucial for building projects and managing user demands in open source can be challenging. The addition of the max pages option improved performance and avoided unnecessary refetches. Inversion of control gives users flexibility, but mistakes can happen in API design. Open source requires time management and feedback from users. API design is influenced by typing ease and good TypeScript support. Getting involved in open source involves trial and error and joining community platforms like TanStack Discord. Dominik's journey started during the pandemic and he can be found on Twitter, TanStack Discord, and his blog.

Workshops on related topic

Masterclass de Depuración de Rendimiento de React
React Summit 2023React Summit 2023
170 min
Masterclass de Depuración de Rendimiento de React
Top Content
Featured Workshop
Ivan Akulov
Ivan Akulov
Los primeros intentos de Ivan en la depuración de rendimiento fueron caóticos. Vería una interacción lenta, intentaría una optimización aleatoria, vería que no ayudaba, y seguiría intentando otras optimizaciones hasta que encontraba la correcta (o se rendía).
En aquel entonces, Ivan no sabía cómo usar bien las herramientas de rendimiento. Haría una grabación en Chrome DevTools o React Profiler, la examinaría, intentaría hacer clic en cosas aleatorias, y luego la cerraría frustrado unos minutos después. Ahora, Ivan sabe exactamente dónde y qué buscar. Y en esta masterclass, Ivan te enseñará eso también.
Así es como va a funcionar. Tomaremos una aplicación lenta → la depuraremos (usando herramientas como Chrome DevTools, React Profiler, y why-did-you-render) → identificaremos el cuello de botella → y luego repetiremos, varias veces más. No hablaremos de las soluciones (en el 90% de los casos, es simplemente el viejo y regular useMemo() o memo()). Pero hablaremos de todo lo que viene antes - y aprenderemos a analizar cualquier problema de rendimiento de React, paso a paso.
(Nota: Esta masterclass es más adecuada para ingenieros que ya están familiarizados con cómo funcionan useMemo() y memo() - pero quieren mejorar en el uso de las herramientas de rendimiento alrededor de React. Además, estaremos cubriendo el rendimiento de la interacción, no la velocidad de carga, por lo que no escucharás una palabra sobre Lighthouse 🤐)
Next.js para Desarrolladores de React.js
React Day Berlin 2023React Day Berlin 2023
157 min
Next.js para Desarrolladores de React.js
Top Content
Featured WorkshopFree
Adrian Hajdin
Adrian Hajdin
En esta avanzada masterclass de Next.js, profundizaremos en conceptos clave y técnicas que permiten a los desarrolladores de React.js aprovechar al máximo Next.js. Exploraremos temas avanzados y prácticas prácticas, equipándote con las habilidades necesarias para construir aplicaciones web de alto rendimiento y tomar decisiones arquitectónicas informadas.
Al final de esta masterclass, serás capaz de:1. Comprender los beneficios de los Componentes del Servidor React y su papel en la construcción de aplicaciones React interactivas, renderizadas por el servidor.2. Diferenciar entre el tiempo de ejecución de Edge y Node.js en Next.js y saber cuándo usar cada uno en función de los requisitos de tu proyecto.3. Explorar técnicas avanzadas de Renderizado del Lado del Servidor (SSR), incluyendo streaming, fetching paralelo vs. secuencial, y sincronización de datos.4. Implementar estrategias de caché para mejorar el rendimiento y reducir la carga del servidor en las aplicaciones Next.js.5. Utilizar Acciones React para manejar la mutación compleja del servidor.6. Optimizar tus aplicaciones Next.js para SEO, compartir en redes sociales, y rendimiento general para mejorar la descubrabilidad y la participación del usuario.
Aventuras de Renderizado Concurrente en React 18
React Advanced 2021React Advanced 2021
132 min
Aventuras de Renderizado Concurrente en React 18
Top Content
Featured Workshop
Maurice de Beijer
Maurice de Beijer
Con el lanzamiento de React 18 finalmente obtenemos el tan esperado renderizado concurrente. Pero, ¿cómo va a afectar eso a tu aplicación? ¿Cuáles son los beneficios del renderizado concurrente en React? ¿Qué necesitas hacer para cambiar al renderizado concurrente cuando actualices a React 18? ¿Y qué pasa si no quieres o no puedes usar el renderizado concurrente todavía?

¡Hay algunos cambios de comportamiento de los que debes estar al tanto! En esta masterclass cubriremos todos esos temas y más.

Acompáñame con tu portátil en esta masterclass interactiva. Verás lo fácil que es cambiar al renderizado concurrente en tu aplicación React. Aprenderás todo sobre el renderizado concurrente, SuspenseList, la API startTransition y más.
Consejos sobre React Hooks que solo los profesionales conocen
React Summit Remote Edition 2021React Summit Remote Edition 2021
177 min
Consejos sobre React Hooks que solo los profesionales conocen
Top Content
Featured Workshop
Maurice de Beijer
Maurice de Beijer
La adición de la API de hooks a React fue un cambio bastante importante. Antes de los hooks, la mayoría de los componentos tenían que ser basados en clases. Ahora, con los hooks, estos son a menudo componentes funcionales mucho más simples. Los hooks pueden ser realmente simples de usar. Casi engañosamente simples. Porque todavía hay muchas formas en las que puedes equivocarte con los hooks. Y a menudo resulta que hay muchas formas en las que puedes mejorar tus componentes con una mejor comprensión de cómo se puede usar cada hook de React.Aprenderás todo sobre los pros y los contras de los diversos hooks. Aprenderás cuándo usar useState() versus useReducer(). Veremos cómo usar useContext() de manera eficiente. Verás cuándo usar useLayoutEffect() y cuándo useEffect() es mejor.
Presentando FlashList: Construyamos juntos una lista performante en React Native
React Advanced 2022React Advanced 2022
81 min
Presentando FlashList: Construyamos juntos una lista performante en React Native
Top Content
Featured Workshop
David Cortés Fulla
Marek Fořt
Talha Naqvi
3 authors
En esta masterclass aprenderás por qué creamos FlashList en Shopify y cómo puedes usarlo en tu código hoy. Te mostraremos cómo tomar una lista que no es performante en FlatList y hacerla performante usando FlashList con mínimo esfuerzo. Usaremos herramientas como Flipper, nuestro propio código de benchmarking, y te enseñaremos cómo la API de FlashList puede cubrir casos de uso más complejos y aún así mantener un rendimiento de primera categoría.Sabrás:- Breve presentación sobre qué es FlashList, por qué lo construimos, etc.- Migrando de FlatList a FlashList- Enseñando cómo escribir una lista performante- Utilizando las herramientas proporcionadas por la biblioteca FlashList (principalmente el hook useBenchmark)- Usando los plugins de Flipper (gráfico de llamas, nuestro perfilador de listas, perfilador de UI & JS FPS, etc.)- Optimizando el rendimiento de FlashList utilizando props más avanzados como `getType`- 5-6 tareas de muestra donde descubriremos y solucionaremos problemas juntos- Preguntas y respuestas con el equipo de Shopify
React, TypeScript y TDD
React Advanced 2021React Advanced 2021
174 min
React, TypeScript y TDD
Top Content
Featured Workshop
Paul Everitt
Paul Everitt
ReactJS es extremadamente popular y, por lo tanto, ampliamente soportado. TypeScript está ganando popularidad y, por lo tanto, cada vez más soportado.

¿Los dos juntos? No tanto. Dado que ambos cambian rápidamente, es difícil encontrar materiales de aprendizaje precisos.

¿React+TypeScript, con los IDEs de JetBrains? Esa combinación de tres partes es el tema de esta serie. Mostraremos un poco sobre mucho. Es decir, los pasos clave para ser productivo, en el IDE, para proyectos de React utilizando TypeScript. En el camino, mostraremos el desarrollo guiado por pruebas y enfatizaremos consejos y trucos en el IDE.