Qué pueden hacer los RSCs en Next.js hoy

Mi nombre es Aurora. Trabajo en el equipo de Next.js en Brasil. Y React Server Components llegó hace unos años. Ha sido todo un viaje. Algunos de ustedes han lanzado aplicaciones de enrutador de aplicaciones con ellos. Algunos de ustedes tal vez los probaron, se retiraron, volvieron a los patrones que ya funcionaban para ustedes, y algunos de ustedes tal vez solo han estado observando desde la línea lateral. Así que esperando ver a dónde va esto. Pero donde sea que estén con ellos, el modelo ha avanzado mucho. Y quiero mostrarles lo que React Server Components puede hacer en Next.js hoy y por qué creo que es el momento más interesante para construir en la web.

Pero antes de hablar sobre Next.js, hablemos sobre React. La historia comienza con algo que ya amamos de React. ¿Por qué amamos React? Puede que no lo hayas pensado realmente o articulado por qué, pero lo sientes cada vez que escribes un componente. React es componible. Puedes construir una fila, una lista de reproducción, una página, unirlas y simplemente funcionan. Así que aquí hay una página con un puñado de componentes de características compuestos juntos. Los componentes de React pueden ser autónomos. Una página diferente puede reutilizar algunas de las mismas piezas mezcladas con nuevas para lo que la página necesita. React nos da límites claros. En otro lugar, los mismos componentes reaparecen, reordenados en otro orden. No tuvimos que saber qué había dentro de cada uno. Así que esa composibilidad es lo que queremos mantener. Todo lo demás en la pila tiene que ganarse su lugar alrededor de eso.

Ahora, los componentes tienen límites claros, entradas claras, salidas claras. Esa es la misma propiedad que hace que un componente sea fácil de razonar para nosotros, también lo hace manejable para un agente. Así que un agente puede tomar una pieza, cambiarla y no tener que entender toda la aplicación para hacerlo de manera segura. Cuanto más grande se vuelve la base de código, más importa eso para el agente, para ti y para tus compañeros de equipo. Y esto no es solo cierto a nivel de componente. La gente está notando esto en la forma de toda la base de código. Así que este es Antonio. Puede que hayas visto su YouTube code with Antonio. Fue genial. Fue como mi camino cuando estaba aprendiendo AppRouter en su día. Pero ha estado construyendo aplicaciones reales con agentes, y lo que también sigue encontrando es este pequeño radio de explosión y límites claros. Así que esta es la misma propiedad, solo escalada al nivel de la base de código. Tal vez eso significaría una carpeta de características en lugar de solo pensar en componentes individuales. Pero ¿cómo se ve todo esto en la práctica cuando comienzas a construir? En el momento en que agregamos datos, la composibilidad se pone bajo presión. Algunos enfoques la mantienen y pagan por ello en otro lugar, y algunos simplemente pierden la composibilidad por completo. Así que vamos a recorrer lo que hemos intentado. Comenzamos con useEffect, nuestro favorito. El componente puede buscar en el renderizado, poseer su bandera de carga, posee la bandera de error y ejecuta la solicitud dentro de useEffect con el arreglo de dependencias correcto. ¿Olvidas una dependencia y obtienes datos obsoletos o agregas una de más y comienzas a buscar en un bucle? Así que por sí solo, se ve bien. Tenemos un componente aquí, top boundary grid, está poseyendo sus datos. Pero luego, en el momento en que otro componente necesita los mismos datos, no podemos simplemente soltar esto dos veces porque ahora estaríamos haciendo la misma búsqueda dos veces. Así que lo elevamos a un componente padre, lo pasamos a través de props, y de repente este componente ya no posee sus datos. Comienza a agregar mutaciones, tienes que elevarlo más alto para ejecutar esos cambios de estado, y de repente tu componente autónomo está conectado a través de tres niveles de props por razones que no tienen nada que ver con la estructura de la interfaz de usuario. Surgió toda una categoría de bibliotecas para limpiar esto. Tuvimos React Query, SWIR, Apollo, Relay. Así que aquí los datos en su lugar estarían claveados y almacenados en caché centralmente para que cualquier componente pueda pedirlos sin perforar props, y las mutaciones pueden invalidar desde cualquier lugar. Y este fue un paso genuino hacia adelante. Y estas bibliotecas siguen siendo una gran opción para muchas aplicaciones hoy en día.

Pero la compensación aquí es que todo esto es client-first. El usuario todavía tiene que descargar el JavaScript y la capa de datos antes de que comience cualquier obtención, y la caché se encuentra fuera del árbol de componentes, por lo que eso significa que típicamente mantenemos dos estructuras, los componentes y luego las claves de consulta. Y esa sobrecarga mental es el precio de la flexibilidad del lado del cliente. En respuesta, algunos frameworks y bibliotecas elevan la obtención de datos a las rutas. Así que en el pages router teníamos getServers.props, React tiene loaders, así que todos convergimos en este mismo patrón. Una única función que obtiene todo lo que la página necesita por adelantado, y luego el resultado puede ser pasado hacia abajo.

Ahora getServers.props mejoró el tiempo general para cargar contenido al obtener en el servidor, pero perjudicó el tiempo para el primer cuadro, porque la página estaría esperando en la consulta más lenta antes de que cualquier cosa fuera pintada. Y la vinculación de datos se movió a la ruta, así que aquí, si tenemos un componente que está leyendo los datos del loader, ya no puedes simplemente soltar esto en cualquier lugar, porque está ligado al loader, tienes que mover el loader, tienes que limpiarlo si lo mueves a otro lugar así que básicamente el componente estaría soldado a la ruta. Y sería más difícil compartir los mismos datos a través de diferentes diseños o rutas. Así que cada uno de estos resolvió un problema real, pero cada uno también agregó un concepto, y cada vez el componente se volvió un poco más ligado a la capa que obtiene sus datos.

Ahora con React server components, la obtención permanece en el servidor, justo al lado de la base de datos, la API, el sistema de archivos, donde sea que los datos realmente vivan, así que el mismo componente aquí una vez más, ahora es una función async, espera su consulta directamente donde se renderiza y devuelve la UI. Y mira lo que regresó aquí, composición. Así que el componente ahora puede poseer sus datos nuevamente. Puedes soltar esto en cualquier lugar y simplemente funcionará. Y el modelo de React siempre ha sido declarativo, describe lo que debería suceder y deja que React coordine cuándo. Ahora suspense extiende eso a async donde la carga se convierte en parte de ese modelo, por lo que podemos envolver las partes que dependen de los datos, darles un fallback y hacer que el contenido fluya cuando esté listo. También podemos usar límites de error para componer de la misma manera declarativa.

Ahora con este patrón, lo que revela cuándo o qué errores dónde es nuestra elección. Así que suspense funciona para la división de código o cualquier biblioteca de datos del cliente que lo soporte, para promesas, leyendo con use o, sí, muchas formas diferentes de usar suspense. Pero con las aplicaciones renderizadas en el servidor, también puedes transmitir en la UI con suspense, así que esto es lo que cambió RSC. Puedes cambiar dónde vive la coordinación y la obtención de datos y este límite puede estar junto al componente. Así que cada parte del árbol puede aparecer con sus propios datos, lista, sin mover toda la secuencia hacia arriba en la ruta.

Así que dando un paso atrás, ¿qué queremos realmente en nuestras aplicaciones? Bueno, queremos componentes que sean autónomos, que puedas colocar en cualquier página, sin elevar el estado como en use effect, sin integrarlo en una ruta como con un loader, sin mantener un conjunto separado de claves de caché, moverlo libremente, entregarlo a un agente, refactorizarlo en su lugar. También queremos un primer panel rápido, los datos deben obtenerse en el servidor junto a donde viven para que el navegador no tenga que descargar nuestro JavaScript y nuestra capa de datos antes de que comience cualquier cosa. También queremos una UI coordinada, carga, transición, actualizaciones optimistas que se mantengan en sincronía y la página debe decidir qué sucede, no la red. Y queremos fuertes core web vitals, un buen SEO, buen lighthouse y un rendimiento que se mantenga a medida que nuestro producto escala.

Obviamente también queremos datos frescos y cuando algo cambia, tanto la caché del servidor como la caché del navegador deben actualizarse juntas. Y quizás lo más importante, queremos navegaciones que se sientan instantáneas. Hacer clic en un enlace debería mostrar la página, idealmente, en lugar de solo mostrar un esqueleto y debería mostrarse instantáneamente, justo cuando haces clic en el botón. Y ninguna de estas piezas es difícil por sí sola, es solo que cuando tienes datos que viven en diferentes partes del sistema con diferentes reglas, puede complicarse. Así que típicamente pasamos más tiempo coordinando dónde viven nuestros datos que realmente construyendo características.

Ahora, el enrutador de aplicaciones NextGIS llegó con componentes del servidor integrados y eso nos llevó la mayor parte del camino. Componentes autónomos, UI coordinada, core web vitals que se mantienen porque enviamos menos JavaScript y comenzamos a transmitir antes. Tomemos como ejemplo el primer renderizado. Así que estos números provienen de un benchmark que Nadia Makarevich compartió en línea. Así que esta era la misma aplicación en tres implementaciones y limitada con una limitación realista. Es una publicación realmente buena si quieres leer más sobre eso.

Pero los resultados aquí muestran que el tiempo para que el contenido sea visible con la obtención de datos del lado del cliente típicamente toma en este ejemplo 5.1 segundos. Así que tienes el JavaScript, luego obtienes los datos, luego renderizas. Con page-to-server, get-server-side-props, que es el cargador, tomaría 2.15 segundos. Así que los datos están en el servidor, pero la página espera la parte más lenta de la consulta antes de que algo se renderice. Ahora, el enrutador de aplicaciones con RSEs y suspense toma 1.28 segundos, por lo que tendrías el shell renderizado primero y luego las partes lentas se transmiten. Y eso es aproximadamente tres veces más rápido que la obtención de datos del lado del cliente. Y además, ni siquiera envías el JavaScript al cliente. Así que los números están ahí.

Pero el renderizado rápido no es toda la historia. Todavía hay cosas que han frustrado con razón a las personas con el enrutador de aplicaciones. Así que la parte de datos frescos aquí. Durante un tiempo, muchas cosas en Next.js se almacenaron en caché por defecto. Teníamos el caché de obtención, el caché de ruta, el caché de datos. Ni siquiera sé cuántos hay. Así que enviabas algo, y luego el contenido estaría obsoleto, y luego la solución era optar por no almacenar en caché en algún lugar correcto. Y también navegaciones instantáneas. Incluso con todo eso, la navegación aún podría volver a un esqueleto en la página a la que habías estado hace un segundo. Y llegaremos a esto en un minuto.

Pero resolvimos la versión del lado de datos frescos en el primer lado de datos en la versión 16. Se llama cache components. Así que esta es la base sobre la que se construye todo lo demás. Los datos son simples. Es un almacenamiento en caché que se ajusta al árbol de componentes. La misma función que ya escribes, optada en el almacenamiento en caché por componente con una validación que fluye a través del caché del servidor y del cliente con una sola llamada. Y la API es lo suficientemente pequeña como para mantenerla en tu cabeza.

Cache components extiende el modelo declarativo de React a la capa de caché. Así que las mismas funciones que ya escribes con una directiva, y una directiva aquí era necesaria para llevar la capa de infraestructura al modelo de componentes de esta manera declarativa. Así que has usado cache, que opta un componente de página o función en el almacenamiento en caché. No necesitas escribir claves de caché. Simplemente proviene del cierre de argumentos de la función. Cache tag es para etiquetar una parte específica de tus datos para que puedas revalidarla más tarde. Y luego la vida del caché para decir cuánto tiempo va a permanecer fresco. Y en la 16, también cambiamos el valor predeterminado.

Así que a partir de la 16, nada se almacena en caché hasta que lo marques de esa manera. Y eso podría sonar al revés hasta que recuerdes este almacenamiento en caché implícito que teníamos antes donde era realmente confuso. Así que ahora almacenas en caché lo que quieres almacenar en caché. Y vamos a ver todo esto más tarde en la demostración. Ahora cache components manejan un sitio de datos frescos y eso nos lleva a lo que estamos lanzando ahora que son las navegaciones instantáneas. Así que lo que hace que una aplicación se sienta instantánea no es solo que el servidor sea rápido, es que el clic produce algo útil de inmediato. Y hay un umbral aquí donde basado en la investigación alrededor de 100 milisegundos, la UI deja de sentirse instantánea.

Y eso es en realidad más rápido de lo que la mayoría de los CDNs pueden responder con una caché caliente. Así que incluso si la página renderizada por el servidor es objetivamente rápida, si el clic tarda más que eso, va a sentirse lento de todos modos. Así que esto es como el incómodo vacío entre las aplicaciones renderizadas por el servidor o para las aplicaciones renderizadas por el servidor. Puedes tener un gran primer panel de SEO streaming, datos en caché, todo eso y aún perder la sensación de spa en el segundo clic. Así que mientras la red esté delante de ello, no se sentirá tan rápido. Y es por eso que a menudo preferimos spas aunque tengan peores resultados en las pruebas de rendimiento.

Así que en Next 16.3, estamos haciendo que ese clic se sienta instantáneo sin renunciar al renderizado del servidor. Estamos trabajando en estabilizar esta versión en las próximas semanas. Para el usuario, es la diferencia entre hacer clic en un enlace y tener un breve retraso y obtener una respuesta instantánea. Tenemos algo llamado app shells. En lugar de tratar cada página como su propia cosa, Next.js puede preparar una parte compartida genérica de la ruta con anticipación y luego reutilizar ese shell para cada URL en esa ruta. Así que el cliente solo lo ve una vez y lo reutiliza para el resto de la sesión.

Luego lo emparejamos con lo que llamamos prefetching parcial. Solíamos hacer prefetch de manera muy agresiva para cada enlace en el viewport. Podías ver cómo inundaba la pestaña de red y luego el clic aún se sentía lento si no habías obtenido ese prefetch a tiempo. Así que ahora estamos cambiando eso. Así que como tienes este app shell, siempre puedes hacer prefetch de eso en segundo plano y reutilizarlo cada vez que vayas a una ruta. Así que puedes hacer prefetch de esto de manera segura. Es básicamente gratis. Y luego puedes agregar características adicionales, que te mostraremos más adelante, para preparar qué contenido adicional quieres prefetch por ruta. También tenemos cosas en el lado de devtool. Tenemos algo llamado instant insights. Te va a decir dónde tu aplicación no es instantánea y dónde podrías tener un problema de rendimiento para que puedas... Es como TypeScript para tu rendimiento.

Y luego te ayudará a tomar la decisión correcta. Y también tenemos algunas otras cosas, como el inspector de navegación para congelar tu UI prefetch y depurarla. Y una utilidad de playwright para bloquear eso en CI. Así que hay muchas más cosas en 16.3, pero esto es lo importante para la historia instantánea.

Ahora también estamos construyendo Next.js con agentes en mente en todo lo que lanzamos en 16.3. Así que tenemos la base, que es la documentación del bundle que está en tus módulos de Node, versión coincidente con tu versión instalada. Así que no hay datos de entrenamiento obsoletos y tu agente usará las APIs correctas. Combínalo con el servidor dev MCP para darle al agente contexto de aplicación en vivo.

Y también tenemos habilidades oficiales de Next.js próximamente. Así que esta es una integración de primera parte que puede guiar al agente a través de flujos de trabajo reales y verificar cambios. Y también nos enfocamos mucho en errores listos para agentes. Eso significa que enviamos correcciones específicas que el agente puede leer y usar de manera autónoma o con tu ayuda. Así que para unir todo esto vamos a construir un reproductor de música. Déjame mostrarte cómo se ve en el código. Bien. Sí. Así que. Interesante. Ahí vamos. Así que estoy aquí en esta versión de vista previa 16.3 y no hay mucho aquí ahora mismo.

Vamos a volver a eso. Así que comencemos con lo básico. Tengo todas las cosas nuevas habilitadas. Así que ahora mismo no hay mucho aquí. Comencemos simplemente insertando un componente. Hagamos una cuadrícula de reproducción rápida. Y veamos qué pasa.

Lo siento, acabo de recargar esto hace un rato. Ahí vamos. Así que tengo un problema. Y voy a lidiar con eso más tarde por ahora. Solo nota que tengo un nuevo componente aquí que es un componente de servidor que es completamente componible y por sí solo aquí simplemente obteniendo sus datos de la base de datos aquí con algo de retraso. Podemos hacer algo más aquí.

Tal vez queramos algunas más características. Tal vez queramos un más jugado. Y tal vez también queramos algunas listas de reproducción. Sí, eso está en el lugar equivocado tal vez. Oh, sí, porque solo tengo cuatro canciones. Está bien. Está por aquí. Vamos a añadir más. Tal vez algunas listas de reproducción. Navegar. Creo que se llama playlist browse. Sí. Y también añadamos este componente de géneros principales que estaba usando en las diapositivas. Cuadrícula de géneros principales. Ahora esto es genial. Todos son completamente componibles aquí pero tengo algunos problemas.

Y si intento recargar esto, verás que tengo una carga bastante lenta aquí. Así que estos son los insights activándose. Así que aquí realmente veremos el problema exacto donde estamos causando un retraso. Imagina que es un cargador. Tu cargador es como lento. Pero aquí te va a decir que es lento. Puedes solucionar esto ya sea almacenándolo en caché, transmitiéndolo o diciendo explícitamente que quieres que esto sea una página lenta. Y esto también tiene un aviso de agente que puedes simplemente pegar, elegir el que quieras y luego dárselo a tu agente y él lo ejecutará. Así que eso es bastante genial. Voy a hacerlo... Sé cómo hacer esto, así que puedo hacerlo yo mismo. Pero eso es parte de lo que estamos enviando. Estos son los insights instantáneos. Lo siento. De todos modos, queremos transmitir esto para que podamos desbloquear esta página.

Así que vamos a hacerlo con suspense. Y aquí vamos a hacer el fallback. Hagamos el esqueleto de la cuadrícula de reproducción rápida. Así que obviamente hice estos perfectos. Oh, fallback. Ahí vamos. Y hagamos lo mismo... Quiero decir, realmente no me importa mi... Lo siento, tengo una cosa de copiar y pegar en el fondo. Ese es el sonido. Pero de todos modos, vamos a añadir otro suspense aquí. Y hagamos simplemente esto de lo más jugado. Lo siento por ese sonido. Debería haber apagado esa aplicación. Y luego veamos. Así que ahora tengo mi suspense aquí, tengo mi suspense aquí. ¿Y qué me perdí ahora? ¿Me perdí algo? Bien, lo más jugado. ¡Oh, gracias! Muchas gracias. Son buenos en esto. Ahí vamos.

Así que tengo esto, tengo mi más jugado, y es como si estuviera transmitiendo, ¿verdad? Y pude diseñar mi secuencia de carga. Esto está debajo del pliegue. Realmente no me importa lo que hay aquí. Déjame poner eso individualmente. Así que ese es el sitio de incidentes diciéndome lo que tengo que arreglar. Y puedes ver que desaparecieron justo ahora. Ahora sigamos adelante. Así que como ya estamos usando las nuevas cosas de React aquí, también podemos animar. Esto no es algo que tal vez recomendaría para tus propias aplicaciones, porque todavía es un poco canario. Pero es bastante genial. Así que déjame hacer esto un poco más agradable y añadir un crossfade a esto. Esto está usando las transiciones de vista. Siempre uso esto porque hace que mis demostraciones se vean bien. Pero eso me dará un buen crossfade cuando transmita esto así. Y todo lo que es...

Todo lo que está fuera de suspense aquí ahora es parte del shell estático. Así que podemos optimizar esto en XJS. Podemos ponerlo en un CDN para que siempre obtengas esta carga rápida inicial y luego transmitir lo que sea más tarde. Muy bien.

Probemos esto. Tengo... Lo siento mucho por esta estúpida música de AI. Lo siento mucho. Pero funciona. Quiero decir... Sí. Veamos por qué está sonando. Así que esto está usando esta fila de reproducción de pista. Está usando nuestro React. Tenemos use client aquí. Use player. Este es un hook enorme. Pero funciona muy bien. Sí. Es agradable. Vamos a reproducir más tarde. No te preocupes. Pero primero vamos a codificar.

Así que, sí. Esto está usando context. Así que puedo envolver context alrededor de mis componentes del servidor. Está bien. De todos modos, vamos a llegar a una lista de reproducción. Porque no creo que esta página exista todavía. Vamos a hacer esta a continuación. Tenemos un poco de trabajo por hacer. Así que estoy aquí en la siguiente página. Ahora también es un stub. Empecemos a llenar algunos componentes aquí. Hagamos un detalle de lista de reproducción. Y voy a necesitar algún tipo de ID aquí. Vamos a obtener eso de los props. Así que puedo hacer... Hagamos params. Así que tenemos este await en Next.js. Así que vamos a resolver esto más tarde. Pero voy a obtener esto de mis props. Y deberíamos poder pasar eso y hacer esta página async. Y tal vez también queramos algunas otras listas de reproducción.

¿Dónde estoy? Ahí vamos. Ese es mi detalle de lista de reproducción. Tal vez también quieras una exploración de listas de reproducción aquí. Y usemos el mismo componente que antes. Simplemente pasemos un ID de exclusión para este. Sí. Ahora, de nuevo, tengo este problema. Puedes verlo allí en los problemas, que es parte de Cache Components, que hemos optimizado. Pero todavía tengo una carga lenta aquí. Va a tomar, como... Es como si estuviera usando un cargador, básicamente. Así que, de nuevo, necesitamos transmitir esto. Así que comencemos haciendo un suspense alrededor de este detalle de lista de reproducción. Hagamos... Bueno, podrías haberlo adivinado, pero voy a hacer un esqueleto de lista de reproducción. Y simplemente envolvamos esto aquí. Y tenemos que hacer lo mismo para la exploración. Así que hagamos lo mismo allí. ¿Es siquiera un componente real? Ni siquiera lo sé. Creo que es lista de reproducción o algo así. Sí. Probemos este. Cuenta tres. Ups. Esta es mi primera vez haciendo una demostración con sonido. Así que... Muy bien.

Ahora está transmitiendo. Tienes esto. Y luego... ¿Verdad? Pero vamos a elegir una lista de reproducción diferente y probar qué sucederá. Así que digamos que elijo esta. ¿Ves cómo este cambio de diseño aquí? ¿Verdad? Esta parte es, como, saltando. ¿Por qué es eso? Bueno, en realidad no sé cuántas canciones tengo en esta lista de reproducción, así que no puedo transmitir esto así. Siempre va a hacer un cambio de diseño. Así que lo genial con suspense es que podemos mover esto como queramos y diseñar la secuencia de carga. Así que esta es una manera. Otra manera es simplemente tener un gran suspense completamente. Es, como... Envolvámoslo aquí. Y eso debería ser... Pero ahora es realmente lento. Es como esperar por ambos. Así que lo que podríamos hacer en su lugar es que realmente podemos mantener este... Hagamos un suspense anidado aquí. Creo que estaría allí. Ahora podemos asegurarnos de no revelar esto hasta que esté listo. Ahí vamos. Así que ahora no tenemos ningún cambio de diseño, y obtenemos la primera parte rápidamente. Bastante bien.

Todavía tengo un problema aquí. Esto se debe a que podrías haber notado si has usado Next, tenemos parámetros async, porque eso significa que podemos optimizar el shell cuando no los esperamos. Así que voy a hacer una solución rápida aquí. Vamos a deshacernos de esto, deshacernos del async, y vamos a hacer algo genial, que es hacer params then. Acabo de aprender esto, y pensé, oye, esto es realmente bueno, en realidad. Así que obtenemos el ID, y luego veamos si podemos devolver esto dentro de aquí. Puede que no pueda... Espera.

¿Qué estoy haciendo mal aquí? Es tan difícil codificar, ¿verdad? Hoy en día. Espera. ¿Cómo funciona JavaScript... Creo que es uno más de esto. Oh, espera. Bien, así. Bien, este debería estar bien. Y luego envolvamos esto aquí. Y por favor ayúdame. Oh, Dios. Y luego, ¿qué me falta? ¿Verdad? ¿Por qué está haciendo eso? Oh, oh Dios mío, mira mi código. Bien, casi estamos allí. ¿Puedes simplemente... Oh, fragmento JSX. Oh, solo, por favor, solo arréglalo. Solo por favor... No, pero esto es... Oh, hizo esto. Ese, ¿verdad? Oh, gracias a Dios. Casi tuve que, como, entrar en pánico y preguntar a la IA allí. De todos modos, sí. Ahí vamos. Así que este es un patrón bastante genial. Es solo JavaScript. Vamos a desestructurar eso fácilmente. Bien.

Así que eso está bien. Así que ahora tenemos esta carga inmediata. Tengo más listas de reproducción aquí abajo. Veamos qué más podemos construir en esto. También podemos animar esto por diversión. Como crossfade. Hagamos un crossfade y veamos qué va a pasar. Debería ser bastante agradable. ¿Por qué qué pasó con mi internet? Está bien. Eso es bastante bueno, ¿verdad? Bien. Probemos la lista de reproducción. Creo que me gusta esta. He estado usando esta aplicación mucho mientras me preparaba, y creo que conozco todas las canciones en este punto. Y luego nota en la lista de reproducción aquí, ¿qué estoy manteniendo aquí? Detalle. Tengo algunos componentes diferentes. Tengo mis componentes de cliente, botón de reproducción, ese es este grande aquí.

Usando el player. Igual que antes, ¿eh? En el contexto. Bastante bien. También podemos añadir límites de error y lo que sea, pero creo que esto está bien por ahora. Así que en realidad, pausemos esto. Tengo como una aplicación completa aquí. Así que he estado construyendo con estos mismos componentes en toda la aplicación y usando estos mismos primitivos. Y notarás que se siente bastante lento ahora mismo. Así que primero, veamos qué hay aquí. Tenemos como una página de "me gusta", que está usando todos los mismos patrones que he estado mostrando. Así que son componentes realmente composables y hermosos, ¿verdad? Estructura de página. Y estamos usando slicing de características. Así que todo esto es como amigable para agentes y fácil de cambiar sin estropear tu base de código.

Así que no creo que vaya a tener tiempo para mostrar todo, pero básicamente lo que puedes hacer con los componentes de cache es que puedes empezar a añadir consultas de listas de reproducción. Puedes empezar a añadir use cache donde quieras ahora optar por el caching porque todavía muestra este tipo de retraso en todo, ¿verdad? Así que puedes añadir use cache donde quieras cachear. Puedes añadir cache life así si quiere importar. Y puedes añadir cache tag para ir adelante y revalidar esto. Y luego para el prefetching, podemos ir adelante y añadir a nuestras páginas. No voy a decir esto porque voy a mostrarte algo genial más tarde. Puedes añadir una nueva cosa que estamos añadiendo, que es export const. Prefetch para permitir runtime. Así que esto significa que estás de acuerdo con el prefetching de datos dependientes del usuario.

Y con todo esto, déjame mostrarte cómo se verá cuando haga esto porque es mucho más genial de lo que te he estado mostrando. Así que nota que estoy como prefetching un montón de cosas aquí. Y después de que esto ya ha sido prefetched, mi aplicación ya es instantánea. Así que solo está reutilizando esos mismos, cada vez que desplazo hacia algo, solo va a reutilizarlos. Y tu aplicación se siente como un spa. Y ese es todo el objetivo de esto. Y si voy adelante y como, ya sabes, hago una nueva lista de reproducción, digo nueva, oh, esa es mi tarjeta. Genial. Verás, ahora ha prefetched todo lo que tiene que ser revalidado para eso. Y puedo ir a nuevo, y ya está ahí. Así que esto es lo que podemos hacer con use cache además de RSCs ahora mismo.

¿Qué más podemos hacer? Bueno, también podemos, digamos que, así que hemos prefetchado todo esto, y ahora podemos continuar y desconectarnos, y podemos acceder a todo lo que ya fue prefetchado. Lo siento. Supongo que quieres escuchar uno. ¿Verdad? Espera, ¿qué es esto? Así que esto ya está prefetchado. Puedo acceder a esto mientras estoy desconectado. Y luego continuar y volver a conectarme. Y, bueno, no se recuperó tan perfecto como en mi demo anterior, pero no está mal.

Muy bien. Creo que tengo que volver a mis diapositivas para no ocupar todo el tiempo aquí. Pero espero que eso te haya mostrado que realmente puedes construir aplicaciones instantáneas. Así que volvamos rápidamente. Déjame ver. Espero no presionar el botón equivocado. Bien. Y voy a concluir aquí muy rápido. Ha sido todo un viaje. La propiedad de la aplicación, ajustamos los valores predeterminados, cometimos errores y los corregimos. Y ahora con este modelo, creo que realmente tenemos lo mejor de ambos mundos donde tenemos estos componentes autónomos, un primer renderizado rápido y navegación instantánea.

Así que obtienes la sensación de una aplicación cliente con la velocidad del servidor. La estructura con la que los agentes también pueden trabajar. Así que un modelo mental y la misma composición en toda la pila. Lo que sea que estés construyendo, si es un sitio de marketing, un blog, un panel de control, una herramienta interna, estos patrones pueden escalar a cada uno de ellos y ayudarte a hacer que cada aplicación sea tan buena como pueda ser. Y eso es lo que puedes hacer con RCS en XJS hoy. Así que si quieres ver la demo, está aquí. La estaré actualizando hasta el lanzamiento con todos los patrones más nuevos. Échale un vistazo. Y contáctame si tienes preguntas. Y mantente atento para un lanzamiento muy próximo. Así que gracias por escuchar. Mi nombre es Aura Sharf en Blue Sky Next. Y disfruta de la conferencia.

Gracias. Primero que todo, gran charla. {{^}}Gracias. ¿Fue instant insights? Sí. ¿Es nuevo en 16.3? Es nuevo en 16.3. De hecho, construí la mayor parte de eso. Genial. Es realmente genial de ver. Sí, gracias. También tengo algunas preguntas al respecto. Así que esta primera es sobre depurar RSCs, especialmente rastrear errores de hidratación o entender por qué un componente se vuelve a renderizar inesperadamente en el servidor puede ser un desafío. ¿Qué mejoras está haciendo el equipo de Next.js para simplificar la depuración? Entonces, ¿los insights instantáneos ayudan? Sí. Básicamente sabemos que ha sido difícil depurar, especialmente RSCs y dónde esperan y cómo obtener un buen rendimiento. Así que ese es todo el punto de los insights instantáneos, tener eso. Cuando habilitas componentes de caché, lo obtienes. Y luego, lo que sea que estés haciendo dentro de tu aplicación, incluso si ya ha sido cargado, estarás recibiendo estas advertencias para cada lugar donde tu aplicación no es instantánea. Increíble. Así que esta siguiente pregunta tiene que ver con, supongo, cómo se propagan los errores. Veamos. Están cambiando alrededor de mí aquí. Pero vamos a saltar a esta. Así que dividir la obtención de datos y la visualización nos permitió tener modelos mentales más simples. Pensar en ello menos tiempo. RSC se siente más complejo de nuevo, acoplando datos y renderizado. ¿Cómo crees que podemos gestionar esto en el futuro? ¿El hecho de que RSC se sienta más complejo acoplando datos? Creo que sí. Creo que la clave está en dedicar algo de tiempo a ver lo que otras personas están haciendo en esta aplicación y copiar esos patrones para asegurarte de no estropear tu base de código. Pero el objetivo es, al menos para nosotros, que no termines con estas estructuras inmantenibles porque te estamos obligando a hacerlo de la manera correcta. Pero sí. Correcto. Quiero decir, fue genial ver la jerarquía de lo que estabas construyendo. Porque quiero decir, típicamente no vería una aplicación como esta construida con Next.js. Esperarías ver algo como use query o algo así. Así que parece que tal vez habrá algunos patrones que salgan de esto en términos de cómo estructuras tus componentes. ¿Cómo te aseguras de que los componentes de nivel inferior hagan la obtención de datos para que puedan ser reutilizados? ¿Puedes hablar un poco sobre cómo conseguiste eso?

Así que he estado trabajando con Next.js durante años y he estado experimentando con esto. Y es solo tal vez recientemente que he estado aterrizando en este modelo que tengo aquí, que compartí en mi blog e hice como una habilidad para que la gente pudiera probarlo. Pero sí, solo manteniendo tus componentes lo más independientes posible y solo obteniendo lo que realmente necesitan y haciendo que obtengan sus propios datos. Es solo, eso es ya lo que necesitas hacer. Eso es ya lo que haces con React query, ¿verdad? Solo les das lo que necesitan y luego obtienen sus propios datos. Básicamente es el mismo modelo mental. Genial. Así que esta siguiente dice, ¿recomendarías hacer la transición de todo a componentes del servidor? ¿Proporcionaría esto un beneficio significativo en comparación con los componentes del cliente en un sitio web existente del lado del cliente? Sí. Quiero decir, depende de lo que quieras decir con convertir todo. Pero si estás usando Next, recomendaría encarecidamente que cuando lancemos esto, lo pruebes, pruebes los componentes de caché y sigas el lanzamiento y veas lo que se supone que debes activar y cómo funciona. Y prueba a convertir partes más altas de tu aplicación usando estos insights instantáneos. Y por supuesto, está totalmente bien hacer obtención de datos del lado del cliente también, si tienes algo interactivo, si tienes como un sitio web o tienes algo que está obteniendo datos en vivo. Puedes hacer eso también. La mayoría de tus aplicaciones deberían estar perfectamente bien con componentes del servidor con este patrón. Genial. Bien, esta siguiente es de un desarrollador de Angular. ¿Por qué estás en una conferencia de React? Pero solo me preguntaba, ¿sería menos código repetitivo agregar el suspense al componente hijo en sí mismo? Así que supongo que en tus demos, estás escribiendo suspense, pones el componente dentro. ¿Funcionaría poner suspense en esos componentes hijos? Así que el punto con suspense, sé que esto es como una confusión porque estamos acostumbrados a poner dentro de los componentes porque ahí es donde están nuestros efectos.

No teníamos realmente una opción. Pero es mejor no... Lo que típicamente sucedería es que cada componente tiene su propio estado de carga y aparecería repentinamente en secuencias aleatorias. Y eso no es una buena UX. Por eso, cuando envuelves el suspense alrededor de los componentes, puedes diseñar la forma en que se supone que debe cargar según tu diseñador o tus requisitos o lo que quieras, en lugar de que esté vinculado a ese componente. Porque el componente no sabe cómo está siendo utilizado. Así que eso depende de dónde lo estés usando. Y creo que vimos eso en tu demo donde pudiste elegir, ¿quieres envolver con suspense ambos o solo uno de ellos? Y supongo que no podrías hacer eso si estuviera dentro. No, exactamente. Así que ese es todo el punto de suspense. Tienes esta carga declarativa que antes, no tendrías eso. Así que solo puedes hacer eso con suspense hasta donde yo sé. Genial.

Bien. Siguiente. Con PPR, la shell estática se descarga antes de que se resuelvan las ranuras dinámicas. Si una ranura dinámica lanza un error después de que la shell ya se ha enviado al cliente, ¿cómo funciona la recuperación de errores? ¿Qué ve realmente el usuario? Así que depende de cómo quieras manejar el error. Así que podrías saber que tenemos enrutamiento basado en archivos, tenemos un archivo error TSX donde puedes capturar errores. Pero también enviamos algo o estamos enviando algo nuevo en 16.3, que es algo así como el React error boundary. Pero para Next, así que tendrá un capturador y un reintento que también revalidará el componente del servidor, refrescará los datos y se asegurará de que no cause ningún cambio extraño de diseño o reactivación o suspense. Así que eso es otra cosa que estamos estabilizando ahora en 16.3.

Para que puedas envolver incrementalmente o granularmente tu árbol y asegurarte de que está manejando tus errores correctamente. Genial. Esta pregunta, de hecho, yo también tengo esta pregunta. ¿El suspense interno espera al suspense externo o comienzan al mismo tiempo? Esto fue cuando en la demo moviste el suspense como un suspense anidado. Así que como estamos poniendo el componente del servidor interno dentro, nos aseguraremos de no esperar por ese antes de revelar el primer contenido. Porque el primer contenido es el más importante, pero tampoco podemos paralelizarlos completamente. Ahí es cuando obtenemos el cambio de diseño. Así que revelamos el primer contenido y luego tenemos otro para cargar eso independientemente después. Entiendo. Y supongo que si ya estás almacenando en caché y estás usando estas cosas de caché, ese componente anidado podría potencialmente cargar instantáneamente. Oh sí. Todas mis páginas estaban cargando instantáneamente porque puse estas nuevas cosas de prefetching por toda mi aplicación, porque típicamente eso es lo que quieres hacer en SPA porque todo es datos de usuario de todos modos. Y entonces realmente no los verías. Pero si te desconectas, los verías o si no tienes el prefetch listo, aún los verías.