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

Rate this content
Bookmark
Github

- Introducción

- Requisitos previos para el masterclass

- Estrategias de obtención de datos: fundamentos

- Estrategias de obtención de datos - práctica: API de obtención, caché (estática VS dinámica), revalidación, suspense (obtención de datos paralela)

- Prueba tu compilación y súbela a Vercel

- Futuro: Componentes del servidor VS Componentes del cliente

- Huevo de pascua del masterclass (no relacionado con el tema, llamando a la accesibilidad)

- Conclusión

53 min
12 Dec, 2022

Comments

Sign in or register to post your comment.

Video Summary and Transcription

Este masterclass en React Day Berlin cubrió estrategias de obtención de datos para el nuevo Directorio de Aplicaciones, incluyendo componentes del servidor, componentes del cliente y obtención de datos dinámica. Next.js introdujo poderosas estrategias de obtención de datos como ISR y ISR bajo demanda, junto con otras mejoras en Next 13. El masterclass enfatizó la importancia de configurar un entorno de desarrollo y crear una compilación de producción para realizar pruebas. También se discutieron los beneficios de utilizar estrategias de caché y revalidación en Next.js para una obtención de datos eficiente. El masterclass concluyó con un enfoque en el streaming con suspense para la transmisión independiente de componentes de la interfaz de usuario y la mejora de la interactividad para los usuarios.

Available in English

1. Introducción al taller y estrategias de obtención

Short description:

Bienvenidos a nuestro taller, React Day Berlin. Soy Alice De Mauro, una ingeniera de ventas en Vercell. Cubriremos las estrategias de obtención para el nuevo Directorio de Aplicaciones, incluyendo componentes del servidor, componentes del cliente y obtención dinámica.

Hola a todos. Bienvenidos a nuestro taller, React Day Berlin, sobre 9CX13 y obtención de datos especialmente en lo que respecta al nuevo directorio de aplicaciones. Soy Alice De Mauro, soy una ingeniera de ventas en Vercell, y una ingeniera de ventas básicamente significa que soy una arquitecta de soluciones para preventas.

Básicamente, verifico la arquitectura de nuestros clientes y veo si Vercell es una opción. ¿Qué es Vercell? Si no lo conoces, creamos y mantenemos SGS. Webpack, tenemos personas trabajando desde Webpack y acabamos de lanzar TurboPack. También tenemos TurboRepo y otras herramientas internas 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 comenzar de inmediato con lo que son nuestros requisitos previos básicamente o al menos lo que voy a usar para el taller. Algo que voy a hacer bastante a menudo es este movimiento aquí. Espero que no sea demasiado brusco, pero estoy acostumbrada a ir a mi entorno de esta manera. ¿Qué tengo? Tengo mi ID. Tengo mi terminal y mi Visual Studio Code. Ya tengo algo de código preparado. El código estará en este lugar.

En realidad, les voy a dar dos enlaces. Uno será el código limpio antes del taller básicamente. Lo voy a dejar en el chat. Esto es público y pueden acceder a él. Simplemente bifurqué uno de nuestros famosos repositorios para el playground de la aplicación Next.js y lo ajusté específicamente para este taller. Lo que voy a hacer es usar la solicitud de extracción para darles la bienvenida a nuestro taller y así pegar o implementar nuestros cambios. Todos los cambios que haga, los verán en esta rama específica de GitHub. También voy a hacer esto, tengo mi panel de control de Vercell. Creé una prueba profesional solo para este taller. ¿Por qué? Porque necesitaba tener todos los comentarios de vista previa habilitados para ustedes. Si voy a mis implementaciones, tengo mi vista previa. Mi vista previa se basa en la rama de bienvenida al taller. Básicamente, aquí voy a pegar esto ahora. Si han iniciado sesión en Vercell, deben pegarlo aquí. Si pueden iniciar sesión en Vercell, entonces pueden comentar en todo lo que está en esta página. Esta será nuestra línea de base del taller.

Por ejemplo, puedo hacer este ejemplo. Veré sus comentarios. Si aún no tienen Vercell, consideren que yo solo tenía OBI, no sé, ayer. Es muy fácil, solo continúen con GitHub, inicien sesión en GitHub y listo. Lo mismo para GitHub y Bitbucket. Luego pueden comentar en esta URL específica. Esta URL también estará disponible después del taller. No se preocupen por las cosas que eventualmente olvidaron preguntar o que no quieren preguntar ahora porque quieren verificar más adelante. Por favor, vayan aquí y comenten. Los recibiré directamente aquí. Luego veré los comentarios en el bot de Versal. Simplemente los revisaré aquí. Creo que en cuanto a lo que vamos a tener, más o menos, listo, está hecho.

Algo más. ¿De qué se trata todo esto? Nuestro taller tratará sobre estrategias de obtención para el nuevo Directorio de Aplicaciones. Les mostraré componentes del servidor, que es básicamente el valor predeterminado para el nuevo Next.js. Componentes del cliente y cómo hacerlo en SUR. El descargo de responsabilidad es que lo hicieron antes, nada diferente. Obtención dinámica y cómo funciona cuando optan por ello, cuando optan por no hacerlo y este tipo de cosas.

2. Estrategias de obtención y componentes del servidor

Short description:

ISR y on-demand ISR son estrategias de obtención poderosas. React Day Berlin acaba de lanzar Next 13, junto con otras mejoras. La documentación Beta está disponible para recibir comentarios. Configurar un entorno de desarrollo y crear una compilación de producción es importante para las pruebas. El directorio de aplicaciones en el nuevo directorio de NestJS refleja las rutas. Los componentes del servidor siempre se renderizan primero en el servidor y se obtienen en tiempo de compilación, eliminando la necesidad de viajes de ida y vuelta entre el cliente y el servidor.

ISR, lo proporcionamos de serie. Es bastante potente. Si no lo has probado, pruébalo. On-demand ISR, nuevamente poderoso, muy, muy poderoso. Esa es probablemente la parte más larga, porque configurar on-demand ISR requiere un poco más de trabajo, no mucho, pero aún así, pero probablemente sea la más larga, y luego cómo funciona el streaming. Entonces, nuestro suspense funciona 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 los data, están estrechamente relacionadas 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 aplicaciones no es lo único que hemos lanzado, por supuesto. También habrá muchas otras cosas, por ejemplo, TurboPack, o la imagen, la fuente, y así sucesivamente, los scripts, todo integrado y mejorado. Entonces, si no lo sabes, o quieres obtener más información, simplemente, ya sabes, pegué allí el enlace. También tenemos, los voy a obtener ahora mismo, la Beta, esto es específico para la estrategia de obtención de data. Pero en general, tenemos la documentación Beta. Si has iniciado sesión en Vercel, también puedes comentar en ellos. Entonces, si encuentras algo que no está claro, por favor, danos tu opinión, ya sabes, cualquier cosa que sea útil para mejorar nuestra documentación, siempre es bueno, especialmente si esperas algo que no está allí, por favor, no dudes en pegar un comentario allí, solo haz clic en este pequeño ícono y puedes comentar. Y nosotros respondemos, así que si hay algo, ya sabes, cosas que no están claras en la documentación, respondemos preguntas en general.

Volviendo al código. Tengo mi IDE aquí y ya tengo algo de código hecho porque, por supuesto, parte del hecho de que soy muy torpe con las manos, tiendo a cometer muchos errores tipográficos, pero aparte de eso, es más fácil, es más rápido, será más rápido pegar el código de algo que ya está creado, de todos modos voy a subir este código, así que lo tendrás en la cuenta de GitHub. Lo primero y más importante, entonces, terminal, una buena terminal, dos cosas muy importantes. Por supuesto, lo primero y más importante, tienes que instalar todo, vas a usar YARN. Normalmente uso npm, mientras en mi carrera como desarrolladora, usé npm todo el tiempo, pero estos días, no sé, me gusta mucho YARN, así que lo estoy usando por ahora, si ejecutas YARN dev, estas son las dos cosas distintivas que son muy importantes. Si usas YARN dev, iniciarás el entorno de desarrollo, que es el entorno de renderizado en el servidor con recarga en caliente, así que cada vez que cambies algo, tal vez muy rápido, y localhost, te mostraré ahora mismo porque tengo localhost aquí, en localhost siempre mostrará mis cambios de inmediato cada vez que haga algún cambio. Algo que vamos a usar más adelante y que 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, es crear una compilación de producción. Voy a ir directamente a eso porque los componentes del servidor son uno de estos ejemplos donde si tienes algo que necesitas probar desde la perspectiva estática, deberás crear un entorno de producción y probar allí, porque solo allí tienes la primera compilación clásica y luego sirves, ¿verdad? Por ahora, voy a comenzar de inmediato. Así que tengo mi aplicación aquí, el directorio de aplicaciones es el nuevo directorio de NestJS. Tengo todo en el archivo package.json, por supuesto, y tengo algunos grupos. Estos grupos no estarán en tu enrutamiento, solo están destinados a ordenar, a vincular, lo siento, tu URL. Básicamente, lo que hice fue, okay, tengo un par de fallbacks debido a las páginas de carga, y así sucesivamente. Algunos videos de YouTube que puedo usar o no, pero lo importante es nuestra obtención. Desde el directorio raíz, localhost slash, vamos a pasar por todo este enrutamiento. Cada ruta se reflejará a partir de estos nombres de las carpetas. Esto es de la misma manera que funciona un clásico NestJS. Entonces, el componente del servidor será una de mis rutas y aquí es donde voy a comenzar. Voy a ir a mi localhost. Entonces, si hago clic en componentes del servidor, que es el primero, verás que el componente del servidor es mi ruta. Entonces, el nombre de la carpeta, exactamente el nombre de la carpeta hecho automáticamente por Next. Componentes del servidor. Explicación de los componentes del servidor. Se ejecutan en el servidor. Siempre se renderizan primero en el servidor. Te mostraré más adelante los componentes del cliente y cómo dividir las pequeñas piezas. Por defecto, se generan de forma estática en el momento de la compilación. Y eso significa que todo se obtendrá en el momento en que se obtenga del servidor. No habrá ningún viaje de ida y vuelta entre el cliente y el servidor. Por lo tanto, no habrá algo 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 esto, dame aquello. Eso no va a suceder porque todo está en el servidor, dentro del servidor y el servidor realizará todo tipo 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 luego ya están construidos.

3. Construyendo Componentes del Servidor y Obteniendo Datos

Short description:

No es necesario obtener más datos. Por eso se reducen las cascadas. Recuerda siempre tener una compilación de producción. La obtención dinámica es cuando no tienes una caché. Cada vez que alguien solicita tu segmento o ruta, se regenerará la página y se recalculará todo. Voy a comenzar a construir mi componente del servidor. Quiero mostrar publicaciones del JSON placeholder. Tengo una ruta dinámica que toma el ID. El diseño es un componente de orden superior que envuelve a todos los hijos. Voy a obtener el título de mis datos y mostrar la fecha de la renderización. Los datos se obtienen de una API utilizando la función de obtención de datos. Los parámetros se toman automáticamente del componente de la página. NeXT maneja esto automáticamente.

No es necesario obtener más data. Por eso se reducen las cascadas. Algo que escribí allí y escribiré así, es recordar siempre tener una compilación de producción. Si te das cuenta de que es estático, no está generado estáticamente, por lo que es dinámico. Por alguna razón, se actualiza constantemente y te mostraré cómo verificar eso. Refrescar significa que estás ejecutando en modo de desarrollo. Es solo el entorno de desarrollo o algo está optando por lo dinámico. Te mostraré la obtención dinámica más adelante y qué significa optar por la obtención dinámica.

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

De acuerdo, voy a comenzar a construir mi componente del servidor. Lo que quiero hacer es mostrar publicaciones del clásico JSON placeholder. Y te mostraré cómo se generarán exactamente así. Componente del servidor. Tengo una ruta dinámica, la ruta dinámica tomará el ID. Por lo tanto, será componente del servidor/barra diagonal y el número de la publicación, 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 siempre será lo mismo. Lo que hice aquí fue simplemente crear estas pequeñas pestañas y estas pestañas serán siempre las mismas en todas las estrategias de obtención de datos. El diseño es un componente de orden superior donde simplemente envuelves a todos los hijos y los hijos son tus páginas y todos los otros hijos de enrutamiento de las otras páginas, todos los otros segmentos.

Por eso, cuando hago clic aquí, todavía veo los hijos que en realidad están dentro de este ID. Veremos que esa página es como tu índice básicamente. Entonces, tu index.tsx y el diseño es el componente de orden superior alrededor y puedes, no voy a profundizar demasiado en esto, pero puedes envolver los diseños y los diseños y realmente tener esta forma aislada de envolver tus páginas de índice a través de todos tus segmentos. Ya tengo esto listo. Sin embargo, todavía tengo que crear mi índice para esta publicación de blog uno, dos. Lo primero que voy a hacer es copiar y pegar este fragmento de código para evitar cometer errores, también porque es mucho código. Una de las cosas que voy a hacer es obtener el título de mis datos. Mis datos serán la publicación, la publicación número uno, la publicación 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. Entonces, lo que sucede cuando llamas a esta función es simplemente pegar un fragmento de HTML, ¿verdad? Y el HTML será la cadena de la fecha donde se creará ese HTML. Esto ayuda a verificar 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 luego realmente puedes ver si está siendo impactado por mi solicitud o no. ¿De qué se trata los datos? Los datos son algo que simplemente obtengo de una API. La función de obtención de datos obtiene los datos de la API REST. Los parámetros son automáticos en las páginas. Entonces, cuando tienes un componente de página según la convención de nomenclatura page.tsxjs, es el que se toma automáticamente. Los parámetros se tomarán automáticamente. Y eso básicamente es este ID. Cuando tenga los parámetros, los parámetros contendrán el ID. Y ahora también te mostraré cuando tenga la función de obtención de datos. Entonces, ahora voy a crear una función de obtención de datos. Y la función de obtención de datos solicitará los parámetros y dentro de este ID. Este nombre será el mismo que estos nombres. Entonces, si lo hubiera llamado ID de publicación de blog, entonces este también debe ser ID de publicación de blog. Porque de lo contrario, no coincidirá el nombre. Todo esto es automático en NeXT. Por lo tanto, NeXT lo hará por sí mismo.

4. Obteniendo Datos y Componentes del Servidor

Short description:

La obtención en React puede almacenar datos en la caché, evitando la duplicación. Es mejor duplicar las obtenciones para la misma ruta en lugar de tenerlas en la parte superior del patrón. Next.js mejora la obtención con estrategias de caché y revalidación. Los parámetros estáticos pueden generarse para las rutas o crearse dinámicamente como parámetros estáticos. Optar por parámetros estáticos debería ser lo predeterminado. Los componentes del servidor siempre optan por lo estático y obtienen datos desde el lado del servidor.

¿Qué hace la obtención de datos en React? Llama a fetch. Así que fetch ahora en React clásico, ha sido un nombre para ser simplemente, ya sabes, el fetch nativo que hicimos en Dublín. Esto significa que puedes almacenar estos datos en la caché. Entonces, cada vez que tienes una obtención en cualquier lugar, pero esa obtención tendrá la misma entrada que otra obtención, no se duplicarán. Por lo tanto, esos datos no se obtendrán dos veces, siempre se obtendrán una vez y luego el resto se obtendrá de la caché.

Lo que los nombres significaban era como obtener ahora, porque va a estar en el lado del servidor, se guardará de una manera que siempre se recuperará una vez en lugar de varias veces cada vez que lo solicites. Por eso es mejor duplicar la obtención para la misma ruta, para la misma URL de la API, en múltiples páginas donde la uses, en lugar de tenerlo en la parte superior del patrón, porque no importa realmente, y es mejor aislar la obtención de datos en general.

Entonces, 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 datos. Next hizo algo más. Como Next está por encima de React, lo que hicimos fue mejorar la obtención con dos cosas, estrategias de caché y estrategias de revalidación. Así que puedes escribir, te lo mostraré más adelante, pero puedes escribir la obtención de datos de manera que decidas cómo funcionará la caché para esa única obtención o cómo funcionará la revalidación con esa única obtención, lo cual no es nativo de React, así que está en Next. Lo que esto hará es simplemente tomar el resto, serializarlo de nuevo a los datos y luego puedo simplemente tener estos datos obtenidos.

Algo que necesito, y hablé con Tim Nelkens sobre esto hace un par de días, cuando creé este ejemplo específico, no me permitía, fue un poco más complejo que esto, así que podría haber sido algo más, pero no me permitía 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 patrones estáticos. Puede ser de dos maneras. Puedes generar todos los parámetros estáticos para esa ruta o simplemente enumerarlos, decir, hey, los IDs de esta publicación van a ser el uno, dos, tres, cuatro, ¿verdad? Y para hacer eso, aún puedes obtener los datos, ¿verdad? Nuevamente, obtener las publicaciones, todas las publicaciones, y luego enumerarlas aquí de esta manera. Esto debe ser el mismo nombre que los patrones, debe ser el mismo nombre dentro de estos corchetes, o simplemente puedes optar por crearlos 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 lo predeterminado? Porque teóricamente, esto debería ser lo predeterminado, ¿verdad? Siempre deberías tener parámetros estáticos porque esto se genera estáticamente. Entonces, sí, la idea aquí es, bueno, si Next.js 13 todavía está en beta, están decidiendo qué hacer, pero considera que si de repente optas por no usar lo estático, por alguna razón, prueba este fragmento de código para ver si vuelve a optar por lo estático. Nuevamente, lo dejaré aquí para que sepas que si quieres crear todas tus publicaciones de blog, puedes hacerlo posible. Pero esto es más que suficiente para optar por lo estático. Mi código está listo. Lo guardaré. Cambiaré a mi terminal. Mi terminal acaba de recargar lo que acabo de cambiar y dentro de mis componentes del servidor, ahora tengo mis publicaciones.

¿Lo dije antes? Puedes ver aquí, ¿verdad? Esta es la renderización. Y puedes ver cuando cambio, justo ahora, está cambiando, 2703, 2705. Esto es dinámico. ¿Qué más puedo verificar, oh, tan grande? Es cada vez que codifico, mira, aquí hay un 200. Eso significa que no está en caché. Eso significa que cada vez que se va a solicitar, solicitar, solicitar de nuevo. ¿Por qué? Porque estoy en modo de desarrollo. Entonces, cada vez que digas, oh, espera, ¿por qué no está optando por lo estático en el modo de desarrollo? Así que voy a matar todo y voy a borrarlo y luego construir y luego iniciar. La construcción creará una compilación de producción real. Entonces, todo lo que se va a generar estáticamente será estático. Todo lo que todavía es dinámico, todo ISR, todo, y luego iniciar simplemente comenzará la aplicación. Considera que no tiene recarga en caliente, por supuesto, así que tendré que matarlo nuevamente cuando tenga que volver al modo de desarrollo, o cuando cambie algo, siempre tengo que matarlo nuevamente y reiniciarlo porque va a producir las nuevas páginas. Listo, así que vuelvo a mi publicación de blog y luego miro este número, no está cambiando, ¿por qué? Porque no lo volverá a obtener, no lo volverá a renderizar. Y si inspecciono, lo que puedes ver, 304, en caché, en caché, en caché porque es estático.

Estos fueron los componentes del servidor, por defecto, siempre optarán por lo estático. Y siempre obtendrán datos desde el lado del servidor. Entonces, el servidor hará el trabajo, sin cascadas, nada de eso. Y para probarlo, prueba la vista de producción. Vamos a pasar a los componentes del cliente porque algo que, por ejemplo, en la documentación beta aún no está, simplemente, ve al SOR y verifica el SOR o React query, cualquier cosa para solicitar desde el componente del cliente tus datos. En ese sentido, quería... Lo siento, no, Google, no, no, no. Oye, Google, para. Debería haber apagado Google. Lo siento, chicos.

5. Componentes del Cliente y Obtención de Datos

Short description:

Los componentes del cliente se utilizan cuando necesitas React o las ventanas, mientras que los componentes del servidor se utilizan para gestionar datos seguros. Las páginas y los diseños siempre se renderizan en el lado del servidor. Para crear un componente del cliente, envuélvelo alrededor de un componente del servidor como las páginas. Utiliza el gancho useClient de React para crear un componente del cliente. Utiliza el gancho usePathname para leer parámetros de la ruta. Obtén datos utilizando una función fetcher y resuelve la promesa. El componente de la publicación del blog devuelve 'cargando' si no hay datos y el título de los datos si no hay errores y hay datos. Utiliza Usbr para llamar a la API de JSON placeholder con el ID y un intervalo de actualización para datos en tiempo real.

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

Los componentes del cliente se ejecutan en tu computadora, en realidad en la computadora del usuario. Utiliza el estado, utiliza los hechos o las cosas que cambian que deben hacerse, estarán en los componentes del cliente. ¿Cómo obtienes datos? Yo uso S Word, puedes usar, por ejemplo, React Query, y así sucesivamente. Recuerda que las páginas y los diseños nunca serán componentes del cliente, siempre se renderizarán en el lado del servidor. Considera que realmente no puedes hacerlos. Si quieres tener un componente del cliente, necesitas envolverlo alrededor de un componente del servidor, que podría ser una página porque la página es tu índice. En el futuro, será posible, en lugar de usar S Word, utilizar el gancho use de React. Sin embargo, aún no está implementado en S13 porque, sí, aún necesita ser implementado porque está en beta. Siempre lo mismo.

Voy a hacer lo mismo. El código va a ser muy, muy similar. Voy a ir a los componentes del cliente. Código muy, muy similar. Todavía tengo la página, que es mi índice para el componente del cliente slash. Y luego tengo la idea de la publicación donde te voy a mostrar el componente del cliente. 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é publicación del blog. Porque la página no puede ser cliente, ¿verdad? Necesito otro componente para envolver al cliente y hacerlo un componente del cliente puro. Tengo que crearlo, por supuesto. Así que simplemente voy a crear, para hacerlo un componente del cliente, uso cliente. Por ahora, te dará un error porque aún no es un componente completo de React, pero el uso del cliente te permitirá utilizar componentes del cliente, que no son gestionados en el lado del servidor.

Algo que tendré que importar, React, por supuesto. Use as var, que es de esta biblioteca que mantenemos, solo para el clásico as var. Si ya sabes lo que es, es solo una API de obtención de datos, de lo contrario, échale un vistazo. Es realmente muy simple de implementar. Utilizaré el gancho usePathname porque, al ser un componente del cliente, no tendré los parámetros, ¿verdad? Entonces, la página tiene los parámetros, que es el ID. Sin embargo, desde el componente del cliente, tendré que leerlos desde la ruta y luego voy a utilizar un fetcher, y el fetcher es simplemente, lo escribí aquí. Déjame ver dónde está aquí en lib. El fetcher es simplemente, es realmente un copiar y pegar de la documentación, es simplemente un fetcher típico que resuelve la promesa del fetcher.

Entonces voy a crear mi bonita publicación del blog, lo que va a devolver, lo haré en partes porque luego es un poco más fácil de comprobar. Simplemente va a devolver 'cargando' si no hay datos y no hay errores y hay datos, entonces el título de los datos de la publicación del blog, que es lo mismo que antes, nada realmente cambió allí. ¿Cómo lo voy a hacer? Lo primero que voy a hacer es recuperar el nombre de la ruta, ¿qué publicación del blog voy a comprobar? ¿Voy a comprobar esa, la dos? ¿Cuál, cuál va a venir del ID? Y luego voy a usar as var, que se ve así. Voy a usar usePathname directamente desde Next, así que tengo la ruta, ¿verdad? De la URL. Usbr llamará a tu, en este caso, la publicación desde JSON placeholder, así que llamamos a tu API con el ID y luego está la posibilidad de tener un intervalo de actualización, parece muy similar a ISR, donde básicamente va a obtener constantemente la nueva página. La diferencia entre ISR es que esto es similar a una encuesta. Entonces, no importa lo que suceda, va a obtener, obtener, obtener. Mientras que ISR, solo obtiene si alguien va a esa página. Borrará la caché, básicamente. Es más similar a eso, más que obtener, obtener, obtener. Esto es útil para datos que son realmente en tiempo real, como datos en tiempo real puros. De acuerdo, voy a guardar. Tenía mi producción aquí en ejecución, así que tengo que matarlo 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 veré en la página cómo va a ir.

6. Obtención Dinámica de Datos y Opciones de Caché

Short description:

Cuando tienes una página dinámica, estás optando por no utilizar la caché y la página siempre se vuelve a renderizar. Puedes configurar opciones de caché a nivel granular para la obtención y la ruta. Algunas funciones como las cookies y las cabeceras son inherentemente dinámicas. Coloca las funciones dinámicas en la hoja más lejana para un renderizado óptimo. Comprueba la publicación del blog de manera dinámica utilizando el mismo código que las páginas del lado del servidor regulares.

Y luego ves la carga. Acabas de ver la carga. En realidad, lo que puedo hacer es, oh, lo siento, enlace incorrecto. Red, puedo limitar la velocidad. Y si limito la velocidad, la última vez te mostré una muy lenta, y no lo sugeriría. Si limito la velocidad, 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 tiempo tarda en cargar. Va a cargar, va a llevar una eternidad. Y luego en cierto punto, esperemos que obtenga mis datos. Tomó una eternidad. No sugeriría hacer GPRS o cosas así a menos que sea realmente necesario, a menos que sea realmente impactante, digamos. Algo interesante aquí es que la página se vuelve a renderizar, pero también, si ves la red, voy a esperar un poco. Creo que son 5,000 intervalos. Así que cada cinco segundos va a obtener. Así nomás. Realmente está sondeando el clásico. Lo uso para un chat. Cuando estaba construyendo un chat y luego la sondeada era cada segundo o algo así a la base de datos directamente para ver si había algún nuevo chat o algo nuevo, como notificaciones, cosas así. Eso era 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 de datos dinámicos? Entonces, cuando tienes una página dinámica en general, eso significa que estás optando completamente, completamente por no utilizar 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 utilizar o utilizar la caché de una manera muy, muy granular. Te voy a dar este enlace a la documentación beta nuevamente. 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 la obtención como para la ruta en sí, puedes optar por utilizar o no utilizar la caché y varios tipos de estrategias para el renderizado de una manera muy, muy granular. Por ejemplo, puedes hacerlo solo para la obtención, pero no para toda la ruta. Potencialmente puedes decir, okay, este segmento completo o ruta va a tener caché, pero luego la obtención específica en esta página específica para este componente específico no va a tener almacenamiento en caché. Así que no va a tener caché en absoluto, porque sé que siempre necesito que sea muy, muy, muy eficiente. No, eficiente no es la palabra correcta, pero digamos desde un punto de vista de actualización, eficiente. Algo muy útil de saber. A veces puedes pensar, esto va a ser todo estático, bien. Va a estar súper optimizado. Pero luego te das cuenta de que haces una compilación de producción y es dinámico. Eso es porque algunas funciones como las cookies, las cabeceras son inherentemente dinámicas, por lo que van a optar por ser dinámicas automáticamente sin que tengas que decirlo explícitamente. Puede ser que sea ese el caso. Lo que normalmente querrás hacer entonces es tal vez poner esas en la hoja, sea cual sea la hoja, la más lejana de todo lo demás, para que todo se envuelva y se vuelva a renderizar correctamente. Te voy a mostrar cómo hacer eso. Dinámico, así que lo mismo. La página está aquí. Página de ID, vamos a hacer exactamente lo mismo. Comprueba la publicación del blog de manera dinámica. El código 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, a las páginas regulares del lado del servidor, que simplemente voy a copiar y pegar exactamente lo mismo.

7. Opciones de Obtención de Datos y Pruebas

Short description:

Tenemos una función de obtención de datos que toma el ID de la publicación del blog como parámetro y lo envía a JSON Placeholder. Se pueden utilizar diferentes opciones para cada obtención, pero ten cuidado con las opciones conflictivas como cache no store y force cache. Optar por la obtención dinámica y actualizar la página durante las pruebas puede ayudar a evitar problemas de caché terminales.

Así que lo mismo, lo mismo, obtén data. Tenemos una función de obtención de data que va a tomar el parámetro que es el ID de la publicación del blog y ese se enviará a JSON Placeholder. Lo que es diferente aquí es que tengo opciones. Esta es cache no store. Esas opciones, simplemente se pueden poner para cada obtención que tengas. Considera que es posible que quieras verificar cómo son los foldbacks porque a veces están, sabes, pueden, por ejemplo, un no store y una caché forzada real, pueden ser enemigos, digamos, están en contraste, por lo que no se pueden hacer juntos al mismo nivel porque de lo contrario, ya sabes, Next no sabrá cuál elegir pero ahora simplemente estoy optando por no usar Estático, estoy optando forzosamente por Dinámico y si voy a reiniciar mi cosa una y otra vez para verificar mi producción, aquí vamos y voy a, siempre actualizo, debería recargarse automáticamente, siempre actualizo cuando mato porque siempre tengo miedo de la caché terminal. Así que si ahora reviso las Publicaciones aquí, veo esta compilación de producción, 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 inspecciono, siempre será 200 cada vez y siempre solicitará todo el contenido porque lo he optado.

8. ISR, Páginas Estáticas y Streaming

Short description:

ISR es una característica elegante de Next.js que permite opciones de caché granulares. Las páginas estáticas son eficientes y ya están generadas. ISR rompe la caché en función de un período de revalidación. Implementar ISR es fácil al optar por la API de obtención de datos y especificar el tiempo de revalidación. El streaming con OnDemand SR permite romper la caché cuando se desee.

Hay varias cosas que decir, no puedo cubrir todo esto porque es mucho pero echa un vistazo, mira cómo puedes configurar de manera muy granular tus opciones de caché porque realmente puedes hacer maravillas. ISR, una característica muy elegante de Next.js y no es común tenerla porque es una estrategia muy compleja 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 se encuentra ISR muy a menudo en los frameworks lo cual es bastante genial tenerlo en Next.js.

Entonces, ¿qué vamos a hacer? Ahora, lo mejor es lo estático porque lo estático, si no tienes ningún data que realmente necesite dinamismo, lo estático va a ser simplemente súper eficiente y ya está generado. 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 cometiste un error tipográfico o el editor de contenido cometió un error tipográfico, eso es típico. ¿Cómo rompes la caché de esa página? ISR viene en tu ayuda en ese sentido. ISR, el ISR puro se basa en el tiempo. Así que habrá un período de revalidación. Por ejemplo, voy a poner creo que 10 segundos. Escribí 10 segundos. Creo que también el código va a ser 10 segundos. Y ese ISR va a cada 10 segundos, cada solicitud que llegue después de esos 10 segundos va a ser el que rompa la caché básicamente. 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 más reciente. ¿Cómo se implementa? También bastante fácil, también será el mismo código porque es más fácil. Voy a pegar el mismo código 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. Luego, revalidar. Esto está en segundos. Luego, revalidar. Simplemente optas por tu API de obtención de data y cada 10 segundos, se volverá a obtener. También tengo mis parámetros estáticos. Me aseguraré de que esto sea estático por la misma razón de la otra página con la discusión que tuve con el equipo Newkins para ver por qué no optaron por eso. Así que ya tengo mis parámetros generados estáticamente que son el post del blog uno y el post del blog dos. Vamos a probarlo. Y tengo que matar. Reconstruir todo. Cada vez tengo que reconstruir porque las páginas van a volver a estar ahí. Así que se va a reconstruir el HTML. Y también Next tiene esta cosa agradable donde ves qué es del servidor y qué es estático y qué es puramente estático y cuáles ya están generados y así sucesivamente. Muy bien, entonces.

Publicar, ver, 08. Lo sé, lo siento. Solo probablemente actualiza, lo siento. Ahora es 26, 27, 26, 27, 26, 37. Mira 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 actualizado y revalidado y la obtención se va a volver a hacer. Es por eso que si me muevo súper rápido, no van a cambiar porque los 10 segundos aún no han terminado, pero tan pronto como los 10 segundos hayan pasado, esa página va a ser, mira 16, va a ser recreada y me la va a enviar. Ahora, por último pero no menos importante, el streaming es bastante fácil, pero esto es un poco más largo. Voy a tratar de que no sea súper lento porque, por supuesto, estoy teniendo en cuenta el tiempo. Entonces, OnDemand SR, igual 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.

9. Busting Cache and Re-validating Posts in CMS

Short description:

Aprende cómo romper la caché y revalidar publicaciones en un CMS utilizando una API simulada. Utiliza process.env para llamar al entorno y recuperar la publicación del blog utilizando la función de obtención de datos. Opta por lo estático por seguridad, ya que algunas características beta pueden no estar habilitadas. Crea un webhook en la carpeta de la API para romper la caché. La ruta para el webhook es /api/revalidate.

Puede ser que sean páginas antiguas y no quieras que nadie las rompa o tal vez quieras tener una revalidación que sea bastante larga, dos días, pero cada vez que cambies una publicación en un CMS, por ejemplo, en un CMS sin cabeza, tu editor de contenido, tal vez quieran publicarla inmediatamente porque las noticias de última hora ya pasaron o el Black Friday ya terminó, ahora, así que necesito romper la caché inmediatamente.

Un poco más de trabajo, pero no es mucho realmente. Solo hay un par de cosas que necesitamos saber. Lo que voy a usar aquí es esta API simulada realmente linda. Así que voy a pegar el código, perdón, el enlace aquí. Lo descubrí hace como tres o cuatro días. Así que tienes que suscribirte, suscribirte de forma gratuita. Es gratis por ahora. Al menos para cosas básicas, básicas de hobby. Te dan un enlace, un enlace HTTPS, y luego creas un recurso, que básicamente es tu punto final. Y creé mis publicaciones aquí, y puedes agregarlas con los datos falsos que crean. Y si revisas los datos, puedes cambiarlos. Así que puedes cambiarlos y actualizarlos. Y esto es perfecto para probar el OnDemand SR si funciona o no.

Ok, ¿cómo hacer eso? Voy a cerrar aquí, cerrar este. Lo mismo, lo mismo, siempre vamos a tener las publicaciones y demás. Sin embargo, lo que va a ser diferente es que, déjame pegar para decir las mismas cosas que no van a ser diferentes. Entonces, las cosas que no van a ser diferentes van a ser, por ejemplo, el título de los data. los parámetros de obtención, ¿verdad? Hicimos parámetros como la publicación del blog y básicamente los datos de obtención que utilizan un fetch para recuperar la publicación del blog, ¿verdad? Lo primero es lo primero, ¿cómo voy a llamar a mi entorno? Mi entorno, uso process.env. 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 ahí 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 básicamente es el nombre de tu punto final y lo llamo post. Así que slash post va a ser el punto final. Lo que es bueno, déjame ver si te lo muestra aquí. Sí, lo bueno es que cuando tienes el ID de la publicación, por ejemplo, se genera automáticamente y te va a pedir esa publicación. Así que no tienes que hacer nada. Y luego voy a escribir simplemente la llamada TP. La llamada TP va a ser, ok, devuelve los datos, así que tiene todas las cosas, todo el jazz, y solo por seguridad, opta por lo estático porque, de nuevo, en lo que respecta a la versión beta, puede ser que algunas cosas aún no se activen incluso si quieres. ¿Qué más tendría que hacer? En este caso, la página acaba de crearse. Es una página estática. Nada extravagante. Pero si quiero romper la caché, necesito algo más. Es decir, un webhook. Por lo general, los webhooks están en la API desde el lado del servidor de Next. Y aún no lo tengo. Así que voy a tener que crear una nueva carpeta. Y la carpeta va a ser pages. Pages es la de la otra versión, ¿verdad? De Nexus 12. La API seguirá estando en pages. Así que API es solo tu lado del servidor, la API, el servidor, el backend del frontend, digamos así. Y en mi API de pages, por ahora, la API todavía está ahí. Tal vez cambie más adelante. Pero por ahora, todo lo que tienes en pages API se mantendrá ahí. No va a cambiar. En API, crearé backend, hola. A veces mi editor se esconde solo. Creará una ruta. La ruta será revalidate, es una ruta de 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 código típico de revalidación.

10. Revalidación de caché con token

Short description:

Verifica el token de revalidación. Si el token en los parámetros de consulta coincide con el token de validación en el entorno, se rompe la caché para el ID especificado. La caché permanece hasta que se llame a la API nuevamente.

Lo cual 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. Entonces mi código de revalidación sería Alice. Así que si digo, te 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 verificar si mi entorno de proceso validation token es el mismo. Y luego si no lo es, va a mostrar un error, de lo contrario va a romper la caché para ese único ID que también voy a enviar a través de los parámetros de consulta. Así que voy a enviar desde los parámetros de consulta ambos. Mi secreto, y también la idea de la publicación que voy a romper. Y voy a ver que la otra publicación seguirá siendo la antigua. Eso es todo. También te mostraré ahora cómo funciona. Cómo simplemente rompe la caché. Lo mismo de siempre. Mata todo. Estamos en incremental, ¿verdad? Así que cambiando, no pasa nada, no pasa nada. Actualizar, no pasa nada. La fecha siempre va a ser la misma. Igual, igual, igual, ¿verdad? Voy a cambiar mi API. Nuevo, actualizado. Voy a volver, actualizar. 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 localhost y luego API. Aquí vamos. Revalidar secreto aliche ID uno. Ahora el ID uno tiene la caché rota. Voy a volver, publicación dos. Actualizar, actualizar, actualizar. No pasa nada. Ta da da. Publicación uno. Recién revalidada. Bajo demanda porque llamé a esta API. Y esta API se puede llamar desde cualquier lugar, ¿verdad? Es solo una llamada a la API. Solo la llamé desde el navegador. Y esta se mantendrá en caché hasta que no llame a la misma API dos veces.

11. Streaming with Suspense for Multiple Posts

Short description:

El streaming con suspense permite la transmisión independiente de componentes de la interfaz de usuario, evitando que toda la página se bloquee. Se pueden transmitir múltiples publicaciones simultáneamente, con un retraso personalizable para cada publicación. La funcionalidad de streaming mejora la interactividad y reduce el tiempo de espera para los usuarios. El código para transmitir publicaciones se compartirá en el repositorio de GitHub. Si tienes alguna pregunta, no dudes en preguntar.

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

Streaming significa que cada parte de esta interfaz de usuario que va a estar envuelta en el límite de suspense de React se va a transmitir de forma independiente, lo que significa que tu página no se bloqueará por completo para todo el HTML. Se va a renderizar pieza por pieza. Entonces, 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é, algún embudo inferior va a ser problemático o más lento por alguna razón. Entonces quieres que las páginas, parte de las páginas que sean inmediatamente interactivas, hasta el carrito o la primera página de una lista de productos con varias páginas, cosas así.

¿Cómo se hace eso? Así que vamos a hacer las publicaciones ahora. Así que vamos a tener múltiples publicaciones. Streaming. Ahora es un poco diferente. Así que tengo streaming/barra/posts. Y luego aquí, voy a transmitir múltiples publicaciones al mismo tiempo. Dentro de la página, voy a lanzar toneladas de errores, por supuesto, porque me faltan algunas cosas en este momento, pero ten paciencia. 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. He creado un retraso porque ese retraso mostrará realmente el renderizado, el hecho de que, oye, estoy transmitiendo esto, estoy esperando por esto, y este será tres segundos antes que el otro. Y ya podré interactuar con él sin tener que esperar por el segundo. Lo que necesitaré ahora, voy a crear un archivo nuevo, lo llamo PostScale. No seas un seis, esto es solo UI, así que no voy a explicarlo, es realmente, realmente una interfaz de usuario básica. Lo robé del app playground, como dije, al igual que el resto de parte del código de nuestros propios ejemplos para el app playground. Lo pegaré tan pronto como termine esto. Y luego voy a tener un botón, otra cosa muy de la interfaz de usuario, para que no tengas que tener demasiado, está bien, estoy escribiendo en la nada. Muy, muy rápido, es un botón del cliente. Así que usa el cliente, react. Tengo un estado, así que es puro cliente, ¿verdad?, porque el estado establecido es solo para el cliente, estado puro, y esto simplemente va a contar cada vez que haga clic, esto es por publicación. Así que te mostraré que realmente puedo hacer clic en este mucho antes de que se recupere la otra publicación. Y por último, pero no menos importante, será la publicación real, que es la importante, porque es donde tengo todas las cosas buenas. Así que esta publicación será muy similar al resto. Obtener data, similar. Tengo un botón, tengo la cadena de tiempo local como antes, y aún tengo que obtener data. Y obtener data será exactamente lo mismo, nada cambia aquí, mismo código. La única diferencia es que agregué esta pequeña pieza para simular el retraso, porque de lo contrario no tendría ningún retraso en localhost, ¿verdad? Así que estoy simulando el retraso. El retraso es personalizado por publicación. Entonces la primera publicación fue de tres segundos, la otra sería de seis segundos. Listo. Entonces lo que va a hacer es obtener el retraso, las dos publicaciones simplemente vendrán aquí, ¿verdad?, irán al índice que es la página, comenzarán a transmitir la primera, comenzarán a transmitir la segunda. Pero la primera vendrá mucho antes que la otra, debido a mi falso retraso. Y ahora te lo voy a mostrar. No necesariamente necesito la parte de producción ahora, así que puedo usar simplemente Yarn dev, el clásico Yarn dev, porque va a ser dinámico y está bien. Veamos si las publicaciones funcionan, ta-da. Ahora está funcionando y puedes ver la primera, puedo hacer clic, clic, clic, clic, no importa realmente porque la segunda llegó un poco más tarde y no bloqueará toda la página de la publicación. Nos quedamos un poco sin tiempo, eso fue todo. Voy a publicar, publicar, subir este código para que puedas verlo en vivo en el repositorio de GitHub Si tienes alguna pregunta, accede a los comentarios previos, espero que haya sido útil. Avísame si necesitas algo. Muchas gracias.

Watch more workshops on topic

React Summit 2023React Summit 2023
170 min
React Performance Debugging Masterclass
Featured WorkshopFree
Ivan’s first attempts at performance debugging were chaotic. He would see a slow interaction, try a random optimization, see that it didn't help, and keep trying other optimizations until he found the right one (or gave up).
Back then, Ivan didn’t know how to use performance devtools well. He would do a recording in Chrome DevTools or React Profiler, poke around it, try clicking random things, and then close it in frustration a few minutes later. Now, Ivan knows exactly where and what to look for. And in this workshop, Ivan will teach you that too.
Here’s how this is going to work. We’ll take a slow app → debug it (using tools like Chrome DevTools, React Profiler, and why-did-you-render) → pinpoint the bottleneck → and then repeat, several times more. We won’t talk about the solutions (in 90% of the cases, it’s just the ol’ regular useMemo() or memo()). But we’ll talk about everything that comes before – and learn how to analyze any React performance problem, step by step.
(Note: This workshop is best suited for engineers who are already familiar with how useMemo() and memo() work – but want to get better at using the performance tools around React. Also, we’ll be covering interaction performance, not load speed, so you won’t hear a word about Lighthouse 🤐)
React Summit Remote Edition 2021React Summit Remote Edition 2021
177 min
React Hooks Tips Only the Pros Know
Top Content
Featured Workshop
The addition of the hooks API to React was quite a major change. Before hooks most components had to be class based. Now, with hooks, these are often much simpler functional components. Hooks can be really simple to use. Almost deceptively simple. Because there are still plenty of ways you can mess up with hooks. And it often turns out there are many ways where you can improve your components a better understanding of how each React hook can be used.You will learn all about the pros and cons of the various hooks. You will learn when to use useState() versus useReducer(). We will look at using useContext() efficiently. You will see when to use useLayoutEffect() and when useEffect() is better.
React Advanced Conference 2021React Advanced Conference 2021
174 min
React, TypeScript, and TDD
Top Content
Featured WorkshopFree
ReactJS is wildly popular and thus wildly supported. TypeScript is increasingly popular, and thus increasingly supported.

The two together? Not as much. Given that they both change quickly, it's hard to find accurate learning materials.

React+TypeScript, with JetBrains IDEs? That three-part combination is the topic of this series. We'll show a little about a lot. Meaning, the key steps to getting productive, in the IDE, for React projects using TypeScript. Along the way we'll show test-driven development and emphasize tips-and-tricks in the IDE.
React Summit 2023React Summit 2023
151 min
Designing Effective Tests With React Testing Library
Featured Workshop
React Testing Library is a great framework for React component tests because there are a lot of questions it answers for you, so you don’t need to worry about those questions. But that doesn’t mean testing is easy. There are still a lot of questions you have to figure out for yourself: How many component tests should you write vs end-to-end tests or lower-level unit tests? How can you test a certain line of code that is tricky to test? And what in the world are you supposed to do about that persistent act() warning?
In this three-hour workshop we’ll introduce React Testing Library along with a mental model for how to think about designing your component tests. This mental model will help you see how to test each bit of logic, whether or not to mock dependencies, and will help improve the design of your components. You’ll walk away with the tools, techniques, and principles you need to implement low-cost, high-value component tests.
Table of contents- The different kinds of React application tests, and where component tests fit in- A mental model for thinking about the inputs and outputs of the components you test- Options for selecting DOM elements to verify and interact with them- The value of mocks and why they shouldn’t be avoided- The challenges with asynchrony in RTL tests and how to handle them
Prerequisites- Familiarity with building applications with React- Basic experience writing automated tests with Jest or another unit testing framework- You do not need any experience with React Testing Library- Machine setup: Node LTS, Yarn
JSNation 2023JSNation 2023
170 min
Building WebApps That Light Up the Internet with QwikCity
Featured WorkshopFree
Building instant-on web applications at scale have been elusive. Real-world sites need tracking, analytics, and complex user interfaces and interactions. We always start with the best intentions but end up with a less-than-ideal site.
QwikCity is a new meta-framework that allows you to build large-scale applications with constant startup-up performance. We will look at how to build a QwikCity application and what makes it unique. The workshop will show you how to set up a QwikCitp project. How routing works with layout. The demo application will fetch data and present it to the user in an editable form. And finally, how one can use authentication. All of the basic parts for any large-scale applications.
Along the way, we will also look at what makes Qwik unique, and how resumability enables constant startup performance no matter the application complexity.
React Summit 2022React Summit 2022
173 min
Build a Headless WordPress App with Next.js and WPGraphQL
Top Content
WorkshopFree
In this workshop, you’ll learn how to build a Next.js app that uses Apollo Client to fetch data from a headless WordPress backend and use it to render the pages of your app. You’ll learn when you should consider a headless WordPress architecture, how to turn a WordPress backend into a GraphQL server, how to compose queries using the GraphiQL IDE, how to colocate GraphQL fragments with your components, and more.

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

React Advanced Conference 2023React Advanced Conference 2023
27 min
Simplifying Server Components
Server Components are arguably the biggest change to React since its initial release but many of us in the community have struggled to get a handle on them. In this talk we'll try to break down the different moving parts so that you have a good understanding of what's going on under the hood, and explore the line between React and the frameworks that are built upon it.
React Advanced Conference 2022React Advanced Conference 2022
25 min
A Guide to React Rendering Behavior
Top Content
React is a library for "rendering" UI from components, but many users find themselves confused about how React rendering actually works. What do terms like "rendering", "reconciliation", "Fibers", and "committing" actually mean? When do renders happen? How does Context affect rendering, and how do libraries like Redux cause updates? In this talk, we'll clear up the confusion and provide a solid foundation for understanding when, why, and how React renders. We'll look at: - What "rendering" actually is - How React queues renders and the standard rendering behavior - How keys and component types are used in rendering - Techniques for optimizing render performance - How context usage affects rendering behavior| - How external libraries tie into React rendering
React Advanced Conference 2021React Advanced Conference 2021
39 min
Don't Solve Problems, Eliminate Them
Top Content
Humans are natural problem solvers and we're good enough at it that we've survived over the centuries and become the dominant species of the planet. Because we're so good at it, we sometimes become problem seekers too–looking for problems we can solve. Those who most successfully accomplish their goals are the problem eliminators. Let's talk about the distinction between solving and eliminating problems with examples from inside and outside the coding world.
React Advanced Conference 2022React Advanced Conference 2022
30 min
Using useEffect Effectively
Top Content
Can useEffect affect your codebase negatively? From fetching data to fighting with imperative APIs, side effects are one of the biggest sources of frustration in web app development. And let’s be honest, putting everything in useEffect hooks doesn’t help much. In this talk, we'll demystify the useEffect hook and get a better understanding of when (and when not) to use it, as well as discover how declarative effects can make effect management more maintainable in even the most complex React apps.
React Summit 2023React Summit 2023
32 min
Speeding Up Your React App With Less JavaScript
Too much JavaScript is getting you down? New frameworks promising no JavaScript look interesting, but you have an existing React application to maintain. What if Qwik React is your answer for faster applications startup and better user experience? Qwik React allows you to easily turn your React application into a collection of islands, which can be SSRed and delayed hydrated, and in some instances, hydration skipped altogether. And all of this in an incremental way without a rewrite.
React Summit 2022React Summit 2022
20 min
Routing in React 18 and Beyond
Top Content
Concurrent React and Server Components are changing the way we think about routing, rendering, and fetching in web applications. Next.js recently shared part of its vision to help developers adopt these new React features and take advantage of the benefits they unlock.In this talk, we’ll explore the past, present and future of routing in front-end applications and discuss how new features in React and Next.js can help us architect more performant and feature-rich applications.