Next.js 13: Estrategias de Obtención de Datos

Hola a todos. Bienvenidos a nuestra workshop, React Day Berlin, acerca de 9CX13 y data fetching especialmente en lo que respecta al nuevo directorio de aplicaciones. Soy Alice De Mauro, soy ingeniera de ventas en Vercell, y ser ingeniera de ventas significa básicamente que soy una arquitecta de soluciones para pre-ventas.

Así que básicamente, reviso la architecture de nuestros clientes y veo si Vercell es una tarifa. ¿Qué es Vercell? Si no lo sabes, creamos y mantenemos SGS. Webpack, tenemos personas trabajando desde Webpack y acabamos de lanzar TurboPack. También tenemos en casa TurboRepo y otras herramientas que podrían ser útiles para los desarrolladores, en general, si no nos conoces, somos los creadores del legendario Next.js, que es el framework para React.

Voy a empezar inmediatamente con cuáles son nuestros requisitos básicos o al menos lo que voy a usar para tu workshop. Algo que voy a hacer bastante a menudo es este movimiento aquí. Espero que no sea demasiado brusco, pero estoy realmente acostumbrada a ir por mi entorno de esa manera. ¿Qué tengo? Tengo mi ID. Tengo mi terminal y mi Visual Studio code. Ya tengo algo de code preparado. El code va a estar en este lugar.

En realidad, voy a darles dos enlaces. Uno va a ser el code limpio antes de la workshop básicamente. Lo voy a dejar en el chat. Esto es público y puedes acceder a él. Simplemente hice un fork de uno de nuestros famosos repositorios para el playground para la aplicación Next.js y lo ajusté específicamente para esta workshop. Lo que voy a hacer es usar la solicitud de pull para dar la bienvenida a nuestra workshop con el fin de pegar o desplegar nuestros cambios. Todos los cambios que voy a hacer, los verás en esta rama específica de GitHub. Lo que también voy a hacer, tengo mi tablero de Vercel. Creé un ProTrial solo para esta workshop. ¿Por qué? Porque lo necesitaba para tener todos los comentarios de vista previa habilitados para ustedes. Si voy a mis despliegues, tengo mi vista previa. Mi vista previa se basa en la rama de bienvenida a la workshop. Básicamente, aquí ahora voy a pegar este. Si estás registrado en Vercel, tienes que pegarlo aquí. Si puedes iniciar sesión en Vercel, entonces eres capaz de comentar todo lo que está en esta página. Esta va a ser nuestra línea de base para la workshop.

Por ejemplo, puedo hacer este ejemplo. Voy a ver tus comentarios. Si aún no tienes Vercel, considera que tuve OBI justo, no sé, ayer. Creo que ayer tuve OBI. Es súper fácil, simplemente continúas con GitHub, simplemente inicias sesión en GitHub y listo. Lo mismo para GitHub y Bitbucket. Entonces puedes comentar en esta URL específica. Esta URL también se mantendrá después de la workshop. No te preocupes por las cosas que olvidaste preguntar o que no quieres preguntar ahora porque quieres revisar cosas más adelante. Por favor, simplemente ve aquí y comenta. Voy a recibirlos directamente aquí. Luego los comentarios, los van a ver en el bot de Versal. Simplemente los revisaré aquí. Creo que en lo que respecta a lo que vamos a tener, más o menos, listo, está hecho.

Algo más. ¿De qué se trata todo esto? Nuestra workshop será sobre estrategias de obtención de datos para el nuevo Directorio de Aplicaciones. Voy a mostrarles componentes de servidor, que es básicamente el predeterminado para el nuevo Next.js. Componentes de cliente y cómo hacerlo en SUR. La advertencia es como lo hiciste antes, nada diferente. Obtención de datos dinámica, y cómo funciona cuando optas por entrar, cuando optas por salir, y este tipo de cosas.

ISR, lo proporcionamos de serie. Es bastante poderoso. Si no lo has probado, pruébalo. On-demand ISR, de nuevo, muy, muy poderoso. Probablemente sea la parte más larga, porque configurar on-demand ISR requiere un poco más de trabajo, no mucho, pero aún así, probablemente será la más larga, y luego cómo funciona el streaming. Así es como funciona nuestro suspense en general, porque eso es de React, y cómo funcionará junto con Pagesy. Todas estas son estrategias de obtención, pueden ser desde la perspectiva de data, están estrechamente vinculadas con la perspectiva de la página, también es cómo se renderizan básicamente las páginas y las rutas.

Solo para que lo sepas, si no conoces Next, o nunca lo has usado, acabamos de lanzar Next 13. El directorio de la aplicación no es lo único que hemos lanzado, por supuesto. También habrá muchas otras cosas, por ejemplo, TurboPack, o la imagen, la fuente, etc., los scripts, todos integrados y mejorados. Así que si no lo sabes, o quieres comprobar más, solo, ya sabes, pegué el enlace allí. También tenemos, voy a buscarlos ahora mismo, los Beta, esto es específico para la obtención, estrategia de obtención de data. Pero en general, tenemos los docs Beta. Si estás registrado en Vercel, también puedes comentar en ellos. Así que si encuentras algo que no está claro, por favor danos tu opinión, ya sabes, cualquier cosa que sea útil para mejorar nuestros docs, siempre es bueno, especialmente si esperas algo que no está allí, por favor no tengas miedo de pegar un comentario allí, solo tienes que hacer clic en este pequeño icono y puedes comentar. Y respondemos, así que si hay algo, ya sabes, cosas que no están claras en los docs, respondemos a las preguntas en general.

Así que volvamos al code. Así que tengo mi IDE aquí y voy a tener algo de code ya hecho porque por supuesto, parte del hecho de que soy muy torpe con mis manos, así que tiendo a hacer muchos errores tipográficos, pero aparte de eso, es más fácil, es más rápido, va a ser más rápido pegar el code de algo que ya está creado, de todas formas voy a subir este code, así que lo tendrás en la cuenta de GitHub. Primero lo primero, así que, terminal, una bonita terminal, dos cosas que son muy importantes. Por supuesto, lo primero de todo, tienes que instalar todo, vas a usar YARN. Normalmente uso npm, mientras en mis carreras de desarrollador, uso npm todo el tiempo, pero estos días no sé, me gusta bastante YARN, así que estoy usando YARN por ahora, si ejecutas YARN dev, así que estas son las dos cosas distintivas que son muy importantes. Si usas YARN dev, vas a iniciar el entorno de desarrollo, que es el entorno de renderizado del lado del servidor con recarga en caliente, así que cada vez que cambies algo, tal vez super rápido, y localhost, te lo voy a mostrar ahora mismo porque tengo localhost aquí, en localhost siempre mostrará mis cambios inmediatamente cada vez que haga algún cambio. Algo que vamos a usar más adelante es realmente, realmente importante para probar todas nuestras estrategias de obtención, especialmente en lo que respecta a las páginas generadas estáticamente y la obtención estática en general, va a ser crear una compilación de producción. Voy a ir directamente a ello porque los componentes del servidor es uno de estos ejemplos donde si tienes algo que necesitas probar desde la perspectiva estática, necesitarás crear un entorno de producción y probar allí, porque solo allí, realmente tienes la primera compilación clásica y luego sirves, ¿verdad? Por ahora solo voy a empezar. Así que tengo mi aplicación aquí, el directorio de la aplicación es el nuevo directorio NestJS. Tengo todo en el paquete de JSON por supuesto, y tengo algunos agrupamientos. Estos agrupamientos no van a estar en tu enrutamiento, solo están destinados a ordenar, para atar, lo siento, tu URL. Así que básicamente lo que hice fue como, okay, tengo un par de fallbacks porque son las páginas de carga y así sucesivamente. Algunos youtube que podría o no usar, pero lo que es importante es nuestra obtención. Así que desde el directorio raíz, localhost slash, vamos a pasar por todas estas rutas. Cada ruta individual se reflejará desde estos nombres desde las carpetas. Esta es la misma forma en que funciona un NestJS clásico. Así que el componente del servidor va a ser una de mis rutas y aquí es donde voy a empezar. Voy a ir a mi localhost. Así que si hago clic en componentes del servidor, que es el primero, ves que el componente del servidor es mi, mi ruta. Así que el nombre de la carpeta, exactamente el nombre de la carpeta automáticamente hecho por next. Componentes del servidor. Así que explicación de los componentes del servidor. Están corriendo en el servidor. Siempre van a ser automáticos. Las páginas y los layouts son siempre, siempre componentes del servidor. Siempre, siempre van a ser renderizados primero en el servidor. Te mostraré más adelante los componentes del cliente y, ya sabes, cómo dividir los pequeños pedazos. Por defecto son generados estáticamente en tiempo de compilación. Y eso significa que todo va a ser obtenido en el momento en que vas a ser obtenido desde el servidor. No va a haber ningún viaje de ida y vuelta entre el cliente y el servidor. Así que no va a haber algo así como, oh, tengo el cliente, tengo todo mi JavaScript y luego necesito las publicaciones de mis entradas de blog, ¿verdad? Y luego tengo que preguntar de ida y vuelta al servidor. No, dame este, dame aquel. Así que eso no va a suceder porque todo está en el servidor, dentro del servidor y el servidor va a hacer todas estas clases de obtenciones sin ningún viaje de ida y vuelta entre el cliente y el servidor. Y eso es súper, súper rápido porque entonces ya están construidos.

No hay necesidad de obtener más data. Por eso se reducen las cascadas. Algo que escribí allí y escribiré así, es recordar siempre tener una advertencia de compilación de producción. Si te das cuenta de que es estático, no es estáticamente generado, por lo que es dinámico. Por alguna razón se refresca constantemente y te voy a mostrar cómo comprobar eso. Se refresca, refrescar significa o que estás ejecutando en dev. Así que es solo el entorno de desarrollo o algo está optando por lo dinámico. Te mostraré la obtención dinámica más tarde y qué significa optar por la obtención dinámica.

La obtención dinámica es donde no tienes una caché. Cada vez que alguien solicita tu segmento o ruta, segmento y ruta es lo mismo dentro de SGS, más o menos lo mismo. Cada vez que tienes una solicitud va a regenerar la página y recalcular todo, lo cual es menos optimizado por supuesto, a veces es necesario.

Vale, así que voy a empezar a construir mi componente del servidor. Lo que quiero hacer es mostrar publicaciones del clásico marcador de posición JSON. Y te voy a mostrar cómo van a ser exactamente generadas así. Componente del servidor. Tengo una ruta dinámica, la ruta dinámica va a tomar la ID. Así que será componente del servidor slash el número de las publicaciones, uno, dos, y así sucesivamente. En mi página, solo hay una descripción. El diseño envolverá todo. No voy a explicar demasiado sobre el diseño ahora porque básicamente esto va a ser siempre lo mismo. Lo que hice aquí fue simplemente crear estas pequeñas pestañas y estas pestañas van a ser las mismas una y otra vez dentro de todas las estrategias de obtención de data. Así que el diseño es básicamente una especie de componente de orden superior, donde simplemente envuelves todos los hijos y los hijos son tus páginas y todos los demás hijos de enrutamiento de las otras páginas todos los demás segmentos.

Así que por eso cuando hago clic aquí, todavía veo a los hijos que en realidad es lo que está dentro de esta ID. Veremos que esa página es como tu índice básicamente. Así que es tu index.tsx y el diseño es el componente de orden superior alrededor y puedes no voy a pasar demasiado por él, pero puedes envolver los diseños y diseños y diseños y realmente tener esta forma aislada de envolver tus páginas de índice a través de todos tus segmentos. Así que ya tengo esto listo. Sin embargo, todavía tengo que crear mi índice para este slash uno slash dos blog post. Así que lo primero que voy a hacer, voy a copiar y pegar este pedazo de code para evitar cometer errores también porque es mucho code. Así que una de las cosas que voy a hacer es obtener el título de mis data. Mis data van a ser la publicación, publicación número uno, blog post número dos, y así sucesivamente. Algo que también hago en todas las páginas que voy a crear. Voy a mostrar la fecha de la renderización. Así que lo que pasa cuando llamas a esta función es simplemente pegar un pedazo de HTML, ¿verdad? Y el HTML va a ser la cadena de la fecha en la que se va a crear ese HTML. Esto ayuda a comprobar, si se regenera cada vez o si se genera solo una vez, lo cual es realmente útil. Y siempre tienes que crear uno nuevo porque entonces puedes ver realmente si está siendo golpeado por mi solicitud o no. ¿Qué pasa con data? Así que data es algo que simplemente estoy obteniendo de una API. Fetch data va a ser una función y esa función es la que realmente va a obtener los data de la API REST. Params, es automático en las páginas. Así que cuando tienes un componente de página desde la convención de nombres page.tsxjs, es el uno. Params se va a tomar automáticamente. Y eso es básicamente esta ID. Cuando voy a tener params, params va a tener dentro la ID. Y también te lo voy a mostrar ahora cuando voy a tener la función de obtención de data. Así que ahora voy a crear una función de obtención de data. Y la función de obtención de data va a pedir los params y dentro de esta ID. Este nombre va a ser el mismo que estos nombres. Así que si lo hubiera llamado blog post ID, entonces este tiene que ser blog post ID. Porque de lo contrario no va a coincidir el nombre. Todo esto es automático en NextJS. Así que NextJS va a hacer esto por sí mismo.

¿Qué hace fetch data? Llama a fetch. Así que fetch ahora en React, Classic React, ha sido un nombre para ser solo, ya sabes, el fetch nativo que hicimos en Dublín. Lo que significa que puedes almacenar estos en la caché. Así que cada vez que tienes un fetch en cualquier lugar, pero ese fetch tendrá la misma entrada que otro fetch, esos no se van a duplicar. Así que data no se va a buscar dos veces, también, siempre se va a buscar una vez, y luego el resto simplemente va a recurrir a una caché.

Lo que los nombres significaban era como fetch ahora, porque va a ser del lado del servidor, se va a guardar de una manera que siempre se va a recuperar una vez en lugar de varias veces cada vez que lo extraes. Por eso es mejor re, digamos, duplicar el fetch para la misma ruta, para la misma URL de la API, en varias páginas donde lo uses, en lugar de tenerlo en la parte superior del patrón, porque realmente no importa, y es mejor, ya sabes, aislar tu obtención de data en general.

Así que, en este caso, esta es la hoja de mi árbol, porque es la última ruta que voy a recibir, y es donde voy a obtener mis data. Next, hizo algo más. Entonces, porque Next está encima de React, lo que hicimos fue mejorar fetch con dos cosas, estrategias de caché y estrategias de revalidación. Entonces, puedes escribir, te lo mostraré más tarde, pero puedes escribir el fetch de una manera que decides cómo funcionará la caché para ese único fetch o cómo funcionará la revalidación con ese único fetch, lo cual no es nativo de React, por lo que está en Next. Lo que va a hacer es simplemente tomar el resto, serializarlo de nuevo a los data, y luego simplemente puedo tener estos data extraídos.

Algo que necesito, y hablé con Tim Nelkens sobre esto hace solo un par de días, así que cuando creé este ejemplo específico, no me dejaba, era un poco más complejo que esto, por lo que podría haber sido algo más, pero no me dejaba tenerlo estático. Siempre sería dinámico por alguna razón, por lo que estaba optando por lo dinámico, y descubrimos que necesitábamos esta función para generar los patterns estáticos. Puede ser de dos maneras. Puedes generar todos los parámetros estáticos para esa ruta, o básicamente listarlos, decir, hey, las IDs de este post van a ser uno, dos, tres, cuatro, ¿verdad? Y para hacer eso, todavía puedes hacer fetch, ¿verdad? De nuevo, fetch el post, todos los posts, y luego listarlos aquí de esta manera. Esto necesita ser el mismo nombre de los patterns, necesita ser el mismo nombre dentro de estos corchetes, o puedes simplemente optar por tenerlos creados dinámicamente como parámetros estáticos, porque Next.js 13 todavía está en beta.

Hablando con Tim Nirken, estábamos pensando, ¿debería ser esto el predeterminado, porque teóricamente, esto debería ser el predeterminado, ¿verdad? Siempre deberías tener parámetros estáticos porque esto se genera estáticamente. Entonces, sí, la idea aquí es como, bueno, si Next.js 13 todavía está en beta, están decidiendo qué hacer, pero considera que si ves que de repente estás optando por no ser estático, por alguna razón, prueba este pedazo de code para ver si volverá a optar por ser estático. De nuevo, voy a dejar esto aquí solo para que sepas si quieres simplemente crear todos tus posts de blog, puedes, es posible. Pero esto es más que suficiente para optar por lo estático. Mi code está listo. Lo voy a guardar. Voy a cambiar a mi terminal. Mi terminal acaba de recargar en caliente lo que acabo de cambiar y dentro de mis componentes del servidor, ahora tengo mis posts.

Sin embargo, ¿lo dije antes? Puedes verlo aquí, ¿verdad? Este es el render. Y puedes ver cuando cambio, es justo ahora, está cambiando, 2703, 2705. Esto es dinámico. ¿Qué más puedo comprobar, oh, tan grande. Es cuando hago code, ves, hay un 200 aquí. Eso significa que no está en caché. Eso significa que cada vez va a preguntar, preguntar, preguntar de nuevo. ¿Por qué? Porque estoy en modo dev. Así que cada vez que estás como, oh, espera, ¿por qué no se opta por ser estático en modo dev? Así que voy a matar todo y déjame limpiarlo y solo construir y luego empezar. Así que construir creará un constructor de producción real. Así que todo lo que se va a generar estáticamente va a ser estático. Todo lo que todavía es dinámico, todo ISR, todo, y luego empezar es simplemente empezar. La aplicación, considera que no tiene recarga en caliente, por supuesto, así que tendré que matarlo de nuevo cuando tenga que ir al modo dev, o cuando cambie algo, siempre tengo que matarlo de nuevo y reiniciarlo porque va a producir las nuevas páginas. Listo, así que vuelvo a mi post de blog y luego mira este número, no está cambiando, ¿por qué? Porque no va a volver a buscarlo, no va a volver a renderizarlo. Y si inspecciono, lo que puedes ver, 304, en caché, en caché, en caché porque es estático.

Así que estos eran componentes del servidor, por defecto, siempre van a optar por lo estático. Y siempre van a obtener datos desde el lado del servidor. Así que el servidor va a hacer el trabajo, sin cascadas, nada de eso. Y para probarlo, pruebas la vista de producción. Vamos a ir a los componentes del cliente porque algo que, por ejemplo, en el muelle beta no está todavía, solo están como, hey, ve al SOR y comprueba el SOR o React query, cualquier cosa para simplemente pedir desde el componente del cliente para tus data. A este respecto, quería... Lo siento, no, Google, no, no, no. Hey, Google, stop. Debería haber apagado Google. Lo siento, chicos.

Sí, de todos modos. Entonces, los componentes del cliente, ¿cuándo utilizas componentes del cliente frente a componentes del servidor? Esa es la pregunta, ¿verdad? Utilizas componentes del cliente cuando necesitas React o las ventanas. Así que todo lo que es del lado del cliente para que realmente funcione porque la ventana no va a estar en los componentes del servidor, ¿verdad? De la misma manera que process.env no está en los componentes del cliente. Así que los componentes del servidor, process.env, secretos. Todas las cosas que necesitas gestionar desde una perspectiva de seguridad también, van en los componentes del servidor.

Los componentes del cliente, están ejecutándose en tu ordenador, en el ordenador del usuario en realidad. Así que utiliza el estado, utiliza los hechos o las cosas cambiantes que necesitan hacerse, van a estar en los componentes del cliente. ¿Cómo obtienes data? Yo uso S Word, puedes usar, así que React Query y así sucesivamente. Recuerda que las páginas y los layouts nunca van a ser componentes del cliente, siempre van a ser renderizados en el servidor. Así que considera que realmente no puedes hacerlos. Si quieres tener un componente del cliente, necesitas envolverlo alrededor de un componente del servidor podría ser páginas porque las páginas son tu índice. En el futuro, será posible, en lugar de usar S Word, usar el hook use de React. Sin embargo, todavía no está implementado en S13 porque, sí, todavía necesita ser, por supuesto, implementado porque está en beta. Siempre lo mismo.

Voy a hacer lo mismo. Así que el code va a ser muy, muy similar. Déjame ir a los componentes del cliente. Code muy, muy similar. Todavía tengo la página, que es mi índice para el componente del cliente slash. Y luego tengo la idea del post donde te voy a mostrar el componente del cliente. Así que en la página, todavía voy a mostrar mi renderizado regular, que es este, ¿verdad? Solo la fecha local, que va a ser el renderizado. Y luego voy a tener un componente del cliente, al que llamaré blog post. Así que porque la página no puede ser cliente, ¿verdad? Necesito otro componente para envolver alrededor del cliente y hacerlo puro componente del cliente. Tengo que crearlo, por supuesto. Así que simplemente voy a crear, para hacerlo componente del cliente, use client. Por ahora, te da un error porque todavía no es un componente de React completo, pero use client te optará por los componentes del cliente, que no son gestionados por el servidor.

Algo que tendré que importar, así que mi importación, React, por supuesto. Usa como var, que es de esta biblioteca como var que mantenemos, solo para el clásico como var. Si ya sabes lo que es, es solo una API de obtención de data, de lo contrario, solo échale un vistazo. Es realmente, realmente simple de implementar. Voy a usar el use path name porque siendo un componente del cliente, no tendré los parámetros, ¿verdad? Así que la página, tiene los parámetros, que es la ID. Sin embargo, desde el componente del cliente, necesitaré leerlos desde la ruta, y luego voy a usar un fetcher, y el fetcher es simplemente, lo escribí aquí. Déjame averiguar dónde está aquí en lib. El fetcher es simplemente, es realmente un copiar y pegar de los docs, simplemente es un fetcher típico que simplemente está resolviendo la promesa del fetcher.

Así que voy a crear mi bonito blog post, ¿qué va a devolver, lo hago en piezas porque entonces es un poco más fácil de comprobar. Simplemente va a devolver, loading si no hay data, y no hay error y hay data, entonces el data.title del blog post, que es el mismo que antes, nada realmente lo cambió allí. ¿Cómo voy a hacerlo? Lo primero que voy a hacer es recuperar el nombre de la ruta, ¿qué blog post, voy a comprobar? ¿Voy a comprobar ese, el dos? ¿Cuál, cuál va a venir de la ID? Y luego voy a usar como guerra, que se ve así. Voy a usar use path name de next directamente así que tengo la ruta, ¿verdad? De la URL. Así que, Usbr llamará a tu, en este caso, el post del marcador de posición JSON, así que llamamos a tu API con la ID, y luego hay la posibilidad de tener un intervalo de actualización, parece muy similar a ISR, donde básicamente va a buscar constantemente la nueva página. La diferencia entre ISR es que este solo busca si alguien va a esa página. Rompe la caché, básicamente. Es más similar a eso, en lugar de buscar, buscar, buscar. Esto es útil para data que es realmente en tiempo real, como puros data en tiempo real. Vale, voy a guardar. Tenía mi producción aquí corriendo, así que tengo que matar de nuevo. Y también volveré a ejecutar mi producción. No es super necesario en este caso ejecutar la producción, pero si estás acostumbrado a eso. Y luego voy a ver en la página cómo va a ir.

Y luego ves la carga. Acabas de ver la carga. En realidad, lo que puedo hacer es, oh, lo siento, enlace incorrecto. Red, puedo estrangular. Y si estrangulo, la última vez que intenté uno muy lento, y no lo sugeriría. Si estrangulo, entonces verás la carga porque mi conexión es teóricamente muy lenta, como una conexión 3G o 4G en este caso. Vas a ver realmente cuánto tarda en recogerlo. Así que va a cargar, va a tardar una eternidad. Y luego en un cierto punto, espero que vaya a buscar mis data. Tardó una eternidad. No sugeriría hacer GPRS o cosas así a menos que sea realmente necesario a menos que sea realmente discordante, digamos. Algo interesante aquí es que la página se está volviendo a renderizar, pero también, si ves la red, voy a esperar un poco. Creo que son intervalos de 5,000. Así que cada cinco segundos va a buscar. Así de simple. Es realmente la encuesta clásica. Lo uso para un chat. Cuando estaba construyendo un chat y luego la encuesta era como cada segundo o algo así a la database directamente para ver si había como cualquier nuevo chat o cualquier nueva cosa, como notificaciones, cosas así. Eso fue del lado del cliente, y cómo hacerlo del lado del cliente. Dinámico. ¿Es dinámico el segundo? Déjame ver. Aquí vamos, dinámico. Porque luego vamos a pasar a ISR. ¿Qué es la obtención dinámica de data? Así que cuando tienes una página dinámica en general, eso significa que estás optando completamente, completamente fuera de la caché. Lo que significa que cada vez que alguien solicita esa página, esa página siempre va a volver ya renderizada, ya renderizada. Y se volverá a renderizar cada vez que la solicites. Puedo optar por no usar la caché de una manera muy, muy granular. Te voy a dar este enlace a la beta docs de nuevo. Se llama opciones de configuración de segmento de ruta. Cuando tienes opciones de configuración, o en general, este tipo de opción tanto para fetch como para la ruta en sí, puedes optar por no usar la caché y varios tipos de estrategias para renderizar de una manera muy, muy granular. Por ejemplo, puedes hacerlo solo para fetch, pero no para toda la ruta. Así que potencialmente puedes decir, vale, este segmento entero o ruta va a tener caché, pero luego el fetch específico en esta página específica para este componente específico va a ser no store. Así que no va a haber caché en absoluto, porque sé que siempre lo necesito muy, muy, muy eficiente. No, eficiente no es la palabra correcta, pero digamos desde un punto de vista de actualización, eficiente. Algo que es muy útil saber. A veces puedes pensar, esto va a ser todo estático, bien. Va a ser super optimizado. Pero luego te das cuenta de que haces la construcción de producción y es dinámico. Eso es porque algunas funciones como las cookies, los encabezados son inherentemente dinámicos, por lo que van a optar por ser dinámicos automáticamente sin que tengas que decirlo explícitamente. Podría ser ese el caso. Lo que normalmente podrías querer hacer entonces es tal vez poner esos en la hoja, sea lo que sea la hoja, lo más lejos de todo lo demás, para que todo se envuelva bien y se vuelva a renderizar correctamente. Te voy a mostrar cómo hacer eso. Dinámico, lo mismo. Así que la página está aquí. Página ID, vamos a hacer exactamente lo mismo. Comprueba la publicación del blog de forma dinámica. El code es realmente, realmente similar. Voy a pegar todo porque es tan igual. Espera, pégalo correctamente aquí. Es tan igual a las otras páginas de las páginas regulares del lado del servidor que voy a copiar y pegar exactamente lo mismo.

Entonces, lo mismo, lo mismo, obtener data. Tenemos una función de obtener data que va a tomar el parámetro que es el ID de la publicación del blog y ese se va a enviar al JSON Placeholder. Lo que es diferente aquí es que tengo opciones. Este caché no store. Esas opciones, pueden ser puestas para cada obtención que tengas. Considera que podrías querer verificar cómo son los retrocesos porque a veces son, ya sabes, podrían, por ejemplo, un no store y un force cache real, podrían ser enemigos, digamos, están en contraste por lo que no pueden hacerse juntos al mismo nivel porque de lo contrario, ya sabes, Next no sabrá cuál elegir pero ahora estoy optando por salir de Static, estoy optando forzadamente en Dynamic y si voy a matar mi cosa y reiniciar mi cosa una y otra vez para verificar mi producción, aquí vamos y voy a, siempre refresco, debería recargar automáticamente, siempre refresco cuando mato porque siempre tengo miedo de la caché de la terminal. Así que si ahora reviso las Publicaciones aquí, veo esta construcción de producción, así que teóricamente debería ser solo estática como los comentarios del servidor tal vez pero cada vez que hago clic dirá 36, 38, 40. Así que si lo inspecciono siempre será 200 cada vez y siempre solicitará la cosa entera porque lo excluí.

Varias cosas que decir, no puedo repasar todas estas porque es mucho pero échale un vistazo, mira cómo puedes realmente configurar tus opciones de caché de manera granular porque realmente puedes hacer maravillas. ISR, una característica muy, muy sofisticada de Next.js y no común de tener porque es una estrategia muy compleja para aplicarla desde una perspectiva de programación, no desde una implementación. Así que ahora va a ser súper fácil. Pero en general, sí, no encuentras ISR muy a menudo en frameworks lo cual es bastante genial tener en Next.js.

Entonces, ¿qué vamos a hacer? Ahora, Static es lo mejor porque Static, si no tienes ningún data que realmente necesite dinámicas, Static va a ser simplemente súper eficiente y ya generada. Boom, mi página está ahí. Whoa, yay. Sin embargo, si tu página está ahí y no puedes cambiarla, por alguna razón tal vez hiciste un error tipográfico o el editor de contenido hizo un error tipográfico, eso es típico. ¿Cómo rompes la caché de esa página? ISR viene a tu ayuda en ese sentido. ISR, puro ISR se basa en el tiempo. Así que va a haber un período de revalidación. Por ejemplo, voy a poner creo que 10 segundos. Escribí 10 segundos. Creo que también el code va a ser de 10 segundos. Y ese ISR va a ser cada 10 segundos, cada solicitud que llegue después de esos 10 segundos va a ser la que rompa básicamente la caché. Así que digamos que espero 10 segundos. Un segundo después, alguien solicita esa página, la caché se rompe. Así que esa página va a ser automáticamente la fresca. ¿Cómo implementarlo? También bastante fácil también será el mismo code porque es más fácil. Voy a pegar el mismo code que teníamos antes. Voy a tener un último renderizado para mostrarte cuándo se va a renderizar. Voy a tener los parámetros de obtención y esa obtención de data. A continuación, revalidar. Esto es en segundos. A continuación, revalidar. Simplemente optas por tu API de obtención de data y cada 10 segundos, simplemente va a volver a obtener. Tengo mis parámetros estáticos también. Me aseguraré de que esto sea estático por la misma razón de la otra página con la discussion que tuve con el equipo Newkins para ver por qué no optó. Así que ya tengo mis parámetros generados estáticamente que son la publicación del blog uno y la publicación del blog dos. Probémoslo. Y tengo que matar. Reconstruir todo. Cada vez que tengo que reconstruir porque las páginas van a estar de vuelta otra vez. Así que HTML va a ser reconstruido. Y también en Next tienes esta cosa agradable donde ves qué es servidor y qué es estático y qué es puramente estático y cuándo cuáles ya están generados y así sucesivamente. Muy bien, entonces.

Publicación, ver, 08. Lo sé, lo siento. Probablemente solo refrescar, lo siento. Ahora es 26, 27, 26, 27, 26, 37. Ver cada 10 básicamente. Así que 37, 38, 37, 38. Al mismo tiempo va a ser 47. 48, 49. Así que ves cada 10 segundos, voy a solicitar la página y la caché va a ser rota y eso va a ser refrescado y revendido y la obtención va a ser re-hecha. Por eso si me muevo súper rápido, no van a cambiar porque los 10 segundos no van a, aún no han terminado, pero tan pronto como los 10 segundos se hayan ido, esa página va a ser, ver 16, va a ser re-creada y me la van a enviar. Ahora, casi último pero no menos importante, el streaming es bastante fácil, pero esto es un poco más largo. Voy a tratar de no hacerlo súper lento porque, por supuesto, estoy pendiente del tiempo. Entonces, OnDemand SR, lo mismo que ISR, así que vas a tener páginas generadas estáticamente, pero ¿qué pasa si en lugar de cada pensamiento, cada 10 segundos, quiero que esto sea, quiero que la caché se rompa cuando yo decida. Puede ser cualquier cosa.

Puede ser que sean páginas viejas, y no quieres que nadie simplemente entre y rompa tu caché, o tal vez quieres tener una revalidación que sea bastante larga, dos días, pero luego cuando cambias una publicación en un CMS, por ejemplo, en un headless CMS, tu editor de contenido, tal vez quieran inmediatamente como, oh, espera, vamos a republicar inmediatamente porque las noticias de última hora han terminado o el Black Friday ha terminado justo ahora, ahora, así que necesito romper la caché inmediatamente.

Un poco más de trabajo, pero realmente no es demasiado. Son solo un par de cosas que necesitamos saber. Lo que voy a usar aquí es esta API simulada realmente, realmente linda. Así que voy a pegar el code, lo siento, el enlace aquí. Así que lo descubrí hace como tres, cuatro días. Así que puedes, tienes que suscribirte, suscribirte gratis. Es gratis por ahora. Al menos para cosas básicas, básicas de hobby. Te dan un enlace, un enlace HPS, y luego creas un recurso, que es básicamente tu endpoint. Y creé mis publicaciones aquí, y puedes agregarlas con los datos falsos que ellos crean. Y si revisas los data, puedes cambiarlo. Así que puedes cambiarlo en una actualización. Y esto es perfecto para probar el SR bajo demanda si funciona o no.

Bien, ¿cómo hacer eso? Voy a cerrar aquí, cerrar este. Así que igual, igual, siempre vamos a tener las publicaciones y así sucesivamente. Sin embargo, ahora lo que va a ser diferente va a ser que, déjame pegar para decir las mismas cosas que no van a ser diferentes. Así que las cosas que no van a ser diferentes van a ser como el data.title, los parámetros de obtención, ¿verdad? Hicimos parámetros como la publicación del blog y básicamente la obtención de data que usa un fetch para recuperar la publicación del blog, ¿verdad? Primero que nada, ¿cómo voy a llamar a mi entorno? Mi entorno, uso process.env. Así que básicamente una variable de entorno para tener mi enlace. Así que el enlace que te mostré, el que se crea solo para ti, eso es básicamente lo que va a estar allí para tener tu publicación. Slash post es cómo lo llamé, no puedo recordar, este, post, ¿verdad? Así que cuando creas un nuevo recurso, te va a preguntar cuál es el nombre del recurso que es básicamente el nombre de tu endpoint y lo llamé post. Así que slash post va a ser el endpoint. Lo que es agradable, déjame ver si te muestra aquí. Sí, lo que es agradable va a ser que cuando tienes post ID, por ejemplo, se genera automáticamente y te va a pedir ese post. Así que no tienes que hacer nada. Y luego voy a escribir la llamada TP. La llamada TP va a ser, okay, devuelve los data así que tiene todas las cosas, todo el jazz, y luego solo por seguridad, opta por estático porque de nuevo, en lo que respecta a la beta podría ser que algunas cosas todavía no optan incluso si quieres. ¿Qué más necesitaría hacer? Así que en este caso, la página acaba de ser creada. Así que es una página estática. Nada especial. Pero si quiero romper la caché, necesito algo más. A saber, es un webhook. Normalmente los webhooks están en API desde el lado del servidor de Next. Y todavía no lo tengo. Así que voy a tener que crear una nueva carpeta. Y la carpeta va a ser páginas. Páginas es la que básicamente de la otra versión, ¿verdad? De Nexus 12. API todavía va a estar en páginas. Así que API es solo tu lado del servidor, la API, el servidor, el backend del frontend, digamos así. Y en mi API de páginas, así que por ahora, API todavía está allí. Tal vez cambie más adelante. Pero por ahora, todo lo que tienes en páginas API va a quedarse allí. No va a cambiar. En API, crearé backend, hola. A veces mi editor se esconde. Creará una ruta. La ruta sería revalidate, es una ruta API. Así que va a recoger estos nombres. Así que va a ser slash API slash revalidate. Y allí voy a copiar y pegar el típico, típico código de revalidación.

Que hace lo siguiente. Verifica el token de revalidación. Siempre necesitas un token de revalidación. Lo tengo en mi process.env. Y lo tengo en mi local.env. Así que está aquí. Lo llamo Alice porque es más fácil. Así que mi revalidación code sería Alice. Así que si digo, te lo mostraré. Pero si digo API slash revalidate, y luego un signo de interrogación, y luego en mis parámetros de consulta. Así que voy a ser secreto es Alice. Esto va a comprobar si mi entorno de proceso validation token es el mismo. Y luego si no, va a forzar un error, de lo contrario va a romper la caché para ese único ID que también voy a enviar a través de parámetros de consulta. Así que voy a enviar desde parámetros de consulta ambos. Mi secreto, y también la idea del post que voy a romper. Y voy a ver que el otro post sigue siendo el antiguo. Eso es todo. También voy a mostrarte ahora cómo funciona? Así que cómo esto simplemente rompería la caché. Lo mismo de siempre, lo mismo de siempre. Matar todo. Estamos en incremental, ¿verdad? Así que cambiando, no pasa nada, no pasa nada. Refrescar, no pasa nada. La fecha siempre va a ser la misma. Lo mismo, lo mismo, ¿verdad? Voy a ir y cambiar mi API. Nuevo, actualizado. Voy a volver, refrescar. No pasa nada. No pasa nada. No pasa nada. No pasa nada porque está en caché. Bueno, ¿qué quiero? Es revalidar. Entonces lo que voy a hacer es hacer local host y luego API. Aquí vamos. Revalidar secreto aliche ID uno. Ahora el ID uno tiene la caché rota. Voy a volver, post dos. Refrescar, refrescar, refrescar. No pasa nada. Ta da da. Post uno. Acaba de ser revalidado. Bajo demanda porque llamé a esta API. Y esta API puede ser llamada desde cualquier lugar, ¿verdad? Es solo una llamada API. Solo lo llamé desde el navegador. Y este se quedará en caché hasta que no llame a la misma API en el dos.

Bueno, último pero no menos importante, así que te dejo ir. Transmisión con suspense. ¿Qué hace? Para esto tuve que optar por dinámico porque de lo contrario, por supuesto, cuando estás en el lado del servidor, simplemente va a renderizar todo y eso simplemente va a empujar. Ya renderizaron data y luego lo tienen estático por defecto. Así que tuve que optar por dinámico para mostrarte realmente cómo funciona.

La transmisión significa que cada pieza de esta UI que va a estar envuelta alrededor del límite de suspense de React simplemente se transmitirá de forma independiente, lo que significa que tu página no se bloqueará completamente para todo el HTML. Se va a renderizar pieza por pieza. Así que si una API tarda una eternidad, no tiene que bloquear todo lo demás, ¿verdad? Tal vez quieras que el embudo superior sea inmediato. Y luego no importa si, no sé, cualquier embudo inferior va a ser problemático o más lento por alguna razón. Así que quieres páginas, partes de las páginas que sean inmediatamente interactivas, hasta el carrito o la primera página de una lista de varias páginas de productos, cosas así.

¿Cómo haces eso? Así que vamos a hacer las publicaciones ahora. Así que vamos a tener varias publicaciones. Transmisión. Así que ahora es un poco diferente. Así que tengo transmisión / publicaciones. Y luego aquí, voy a transmitir varias publicaciones al mismo tiempo. Dentro de la página, voy a lanzar toneladas de errores, por supuesto, porque tengo algunas cosas que faltan ahora mismo, pero ten paciencia conmigo. Dentro de la página, voy a hacer esto. Un suspense para la primera publicación y otro suspense por separado para la segunda publicación. Creé un retraso porque ese retraso realmente mostrará la renderización, el hecho de que, hey, estoy transmitiendo esto, estoy esperando esto, y este será tres segundos antes que el otro. Y ya voy a poder interactuar con él sin tener que esperar al segundo. Lo que necesitaré ahora, simplemente voy a, nuevo archivo, lo llamo PostScale. No sea un seis, esto es mera UI, así que no voy a explicarlo, es realmente, realmente una básica UI. Lo robé del playground de la aplicación, como dije, como el resto de algunos del code de nuestros propios ejemplos para el playground de la aplicación. Lo pegaré tan pronto como termine este. Y luego voy a tener un botón, así que otra cosa muy UI, así que no necesitas tener demasiado de, bien, estoy escribiendo en la nada. Muy, muy rápido, es un botón de cliente. Así que uso cliente, react. Tengo un estado, así que es puro cliente, ¿verdad? porque set state es solo para el cliente, puro estado, y esto simplemente va a ser clickeando los conteos básicamente, cada vez que hago clic está contando, esto es por publicación. Así que voy a mostrarte que realmente puedo hacer clic en este mucho antes de que se recupere la otra publicación. Y luego último, pero absolutamente no menos importante, va a ser la publicación real, que es la importante, porque es la que tiene todas las cosas bonitas. Así que esta publicación va a ser muy similar al resto. Recuperando data, similar. Tengo un botón, tengo la cadena de tiempo local como antes, y todavía tengo que recuperar los data. Y recuperar los data será exactamente lo mismo, nada cambia aquí, misma cosa code. La única diferencia es que añadí este pequeño pedazo para fingir el retraso, porque de lo contrario no tendría ningún retraso en localhost, ¿verdad? Así que estoy fingiendo el retraso. El retraso es personalizado por publicación. Así que la primera publicación fue de tres segundos, la otra sería de seis segundos. Hecho. Así que lo que va a hacer es recuperar el retraso, las dos publicaciones simplemente van a venir aquí, ¿verdad? van en el índice que es la página, comienzan a transmitir la primera, comienzan a transmitir la segunda. Pero la primera va a llegar mucho antes que la otra, debido a mi retraso falso. Y ahora te lo voy a mostrar. No necesito necesariamente ahora el bit de producción, así que puedo usar simplemente Yarn dev, el clásico Yarn dev, porque va a ser dinámico y está bien. Veamos si funcionan las publicaciones, ta-da. Ahora está funcionando y puedes ver la primera, puedo hacer clic, clic, clic, clic, realmente no importa porque la segunda llegó un poco más tarde y no bloqueará toda la página de publicaciones. Estamos un poco fuera de tiempo, eso fue todo. Voy a publicar, publicar, empujar este code así en el repositorio de GitHub para que puedas verlo en vivo. Si tienes alguna pregunta, accede a los comentarios de la vista previa, espero que haya sido útil. Avísame si algo. Muchas gracias.