SWR vs React Query: Efficient Data Fetching

Entonces, hola a todos. Creo que es un buen momento para comenzar ahora. Es un minuto después de la hora, algunos minutos más para unirse, pero ya podemos comenzar con los conceptos básicos e introducciones. Estamos aquí en una llamada de Zoom. Si hay algo, ya saben, que necesitan preguntar o si necesitan más tiempo para cualquier cosa, no duden en usar la ventana de chat. De hecho, logré tenerlo funcionando en mi siguiente pantalla, así que espero ver todos sus mensajes. Así que, siéntanse libres de saludar. Díganme de dónde vienen. Espero que el clima sea mucho más agradable de lo que es aquí en Brno, República Checa para mí. Ya está un poco oscuro, pero en realidad es un buen momento para hacer una masterclass y pasar tiempo en línea, ¿saben? En general, espero que todos puedan ver mi pantalla. Actualmente muestra una presentación de PowerPoint. Si pueden hacerme saber si la ven porque probablemente sea el requisito más importante para esta masterclass. Sí. Hola a India. Eso es agradable. Viniendo de Francia, perfecto. De la misma otra manera. Christof, estoy llenando para ti. Es octubre. ¿Qué podemos hacer? Si vienes a Londres la próxima semana, estará a punto de comenzar. Y hay mucha gente allí. Eso es genial. Entonces, sí, allá vamos. Y también tenemos a Praga aquí. Genial. Es un placer conocerlos a todos ustedes. Espero que se diviertan. Van a aprender algo nuevo hoy. Y el mayor logro que haré hoy es simplemente divertirme. Aprender algo nuevo y ver lo que podemos hacer en el tiempo asignado. Ahora, mi objetivo es hacer la masterclass en menos de dos horas para que no perdamos la concentración. Para la mayoría de nosotros, es después del horario de trabajo ahora mismo. Así que vamos a ello. Y veamos qué podemos hacer. Entonces, en primer lugar, soy Andrey. Soy un evangelista de desarrolladores para Content.AI. Somos un proveedor de headless CMS. Pero la masterclass de hoy no va a ser sobre headless CMS en absoluto. Así que esta es solo una diapositiva para que sepan de dónde vengo. En general, vamos a hablar sobre las estrategias de obtención de data. Y la agenda para hoy será la siguiente. Entonces, en primer lugar, quiero mostrarles o quiero hablarles sobre las opciones reales de obtención de data que tenemos en JavaScript. Eso será sobre FetchAPI. Luego vamos a hablar sobre las características advanced en la obtención de data. eso significa cómo manejamos los errores, cómo podemos interceptar solicitudes. ¿Cómo puedes implementar o configurar la política de reintento? Y luego vamos a hablar sobre el procesamiento de la data en el lado de la aplicación. Entonces, ahora lo llamamos obtención de data. Pero las bibliotecas que realmente nos permiten hacer todo eso, también tienen un mecanismo de caché y otras características en su lugar que lo hacen más fácil para nosotros. Entonces, vamos a ver algunos casos de uso advanced también. Vamos a ver los casos de revalidación, eso significa que cuando tienes data en caché, necesitas revalidarla ya sea automáticamente o manualmente, o quieres prevenirla, en realidad, ese también es uno de los casos de uso. Y el último será la paginación, que está casi en cada proyecto que necesita trabajar con algunas listas de data. Eso es todo. Creo que esa es una agenda bastante completa para hoy. Ahora, solo para darles una idea, esto va a ser a nivel introductorio. Si eres un experto en React, tal vez esto sea un poco aburrido para ti, pero habrá muchos ejemplos, muchos casos de muestra, por lo que puedes probarlo por tu cuenta. Si tienes Visual Studio preparado, eso es un buen comienzo. Solo para que sepan, no entraré en los grandes o excelentes detalles de React query o de USEr's VR y así sucesivamente, porque podríamos estar aquí todo el día. Sí, entonces, solo para darles una idea de cómo va a funcionar esto, ahora, por supuesto, esto se está grabando, por lo que si necesitan volver a cualquier punto del webinar o masterclass, pueden hacerlo más tarde, y también compartiré la presentación. Sí, entonces, recibirán todas las diapositivas. Recibirán todos los códigos. No se preocupen en absoluto. Y si hay algo que pueda hacer por ustedes, si necesitan que responda algo o si necesitan más tiempo para hacer los ejercicios, háganmelo saber en la ventana de chat. Hice los ejemplos para que puedan seguirlos. Entonces, les daré los códigos y les daré tiempo para trabajar en los ejemplos. Es muy fácil, nada de qué preocuparse. Es prácticamente solo para que pongan sus manos en el código real, para que no solo miren lo que estoy haciendo sino que también lo prueben por su cuenta. Así que eso es todo sobre la agenda y en primer lugar, lo que quería mostrarles es la muestra de la aplicación, la aplicación con la que trabajaremos porque obviamente para todo lo que hacemos en la masterclass necesitamos tener algún tipo de front-end. Entonces, esto es lo que realmente creé. Es solo una bonita imagen de un avión suizo aterrizando en Zurich pero es solo para hacer que el sitio web se vea bien. Esto está un poco desviado pero eso es porque creo que hay una mezcla de etiquetas HTML en algún lugar pero esta es solo una tabla de vuelos que podría estar en un aeropuerto.

Contiene números de vuelo, orígenes, destinos y así sucesivamente. Realmente no importa lo que la tabla muestre. Se trata de los data y la solicitud de red que vamos a hacer. Solo para que sepas, todos los data están almacenados en un headless CMS. El contenido, como dije, trabajo para ellos pero no vamos a trabajar con el CMS en absoluto. Preparé funciones de Netlify que realmente nos darán los data de los manejadores de API, así que solo para que sepas, nos va a dar data sobre vuelos y esta tabla es algo que queremos lograr tener listado aquí. Habrá más cosas como la página siguiente y anterior y así sucesivamente. Llegaremos a eso pero solo para que sepas, este es el frontend y veremos cómo podemos hacer que funcione. Así que eso es lo más importante ahora.

Otra cosa y esa será la primera tarea para ustedes. Hay un repositorio de GitHub con la URL que está ahora mismo en la pantalla. Voy a enviarles el enlace a él en la ventana de chat para que no tengan que anotarlo de la presentación de powerpoint. Así que si quieren ir allí, hay dos ramas. Una es el inicio de la masterclass, una es los resultados de la masterclass. Así que obviamente querrán empezar con el inicio de la masterclass. El readme es solo una muestra de la creación de la aplicación React, así que no es realmente relevante para esta masterclass. Pero lo que quiero que hagan es simplemente clonar todo el repositorio en algún lugar donde puedan ejecutar código. En algún lugar que podamos abrir con Visual Studio Code. Contiene todos los archivos que necesitaremos. Así que les daré unos minutos para que realmente hagan eso. Así que les daré unos minutos para hacer eso. Y el inicio no va a funcionar. Tampoco va a compilar. Así que no se sorprendan porque tiene algo de código faltante. Pero trabajaremos en eso. Así que les daré unos minutos para hacer eso. El enlace está ahí así que deberíamos estar listos para empezar en unos momentos. Repasemos el repositorio para que estén al día con todo. Así que hay dos partes de lo que vamos a hacer hoy. Nos centraremos mucho en la parte del frontend. Así que la parte del backend está ahí solo para apoyarnos. Y para entender cómo funciona hay una carpeta llamada funciones que tiene cuatro funciones implementadas. Lo que hacen, oh, por cierto, mientras están en eso podrían también ejecutar npm i para instalar todos los paquetes. Ya los tengo aquí así que no tengo que hacerlo, pero podrían querer instalar los módulos de node mientras hablamos del repositorio. Así que, como mencioné los data provienen de un Headless CMS. Ahora el Headless CMS tiene un proyecto en algún lugar, tiene un id de ambiente en algún lugar. Nos da data sobre los vuelos. Ahora, no tenemos que ejecutar esto. Si tienen el CLI de Netlify ejecutándose localmente, puedo darles un id de ambiente que van a tener que pasar a su archivo de ambiente si quieren ejecutar las funciones localmente. Eso también es posible, pero no tienen que hacerlo. Las funciones ya están desplegadas en Netlify. Permítanme darles la dirección de eso. Y eso es en realidad aquí. Así que esta es la URL de todas las funciones. Ya están desplegadas allí. Así que deberíamos ser capaces de obtener resultados similares a los que estoy obteniendo. Esto en realidad está obteniendo todos los vuelos. Esta sería otra función que a veces me dará resultados, a veces me dará 500. Así que parece estar funcionando bien, así que de nuevo pueden ejecutarlo localmente si quieren. Puedo darles el ID del ambiente. Si no quieren ejecutar localmente entonces esta será la dirección que usarán en las llamadas fetch. Así que esa es la primera parte, esas son las funciones. Están configuradas para ser accesibles vía slash API slash nombre de la función. Ven que hay un par de ellas. Todas hacen lo mismo pero la primera en realidad te da todos los vuelos. La lenta en realidad te dará todos los vuelos después de cinco segundos. Así que esto es solo un simulador que podemos reintentar o simular tiempos de espera. Hay una que se llama poco fiable que te dará los resultados solo una vez en cinco intentos. Así que basado en un número aleatorio. Y hay una que aparte de la te dará el número total de vuelos que están disponibles. Así que podemos hacer paginación más tarde. Así que estas son todas las funciones. Es todo bastante igual. Y de nuevo, no tienen que ejecutarlo localmente. Les daré la URL para que puedan ejecutarlo. Podemos trabajar todos con él desde el punto final remoto. Y así es la primera parte. Estas son las funciones. Luego, por supuesto, está el índice TSX.

Es una simple muestra de React, por lo que solo tiene la aplicación dentro. También tiene un proveedor de cliente de consulta. Llegaré a eso más tarde. No lo necesitamos ahora, pero lo necesitaremos más tarde para React Query. Pero solo para que lo sepas, este es el punto de entrada de la aplicación. Luego está el archivo TSX de la aplicación, que es la aplicación principal. Contiene la imagen en el fondo. Contiene los fundamentos de la tabla. Y este es el lugar donde vamos a agregar nuestros componentos más tarde. Así que esta es la aplicación principal. Y hay un montón de scripts. No tenemos que preocuparnos por los scripts. Hay un montón de modelos. De nuevo, no tenemos que preocuparnos por esos, porque esa es una parte del headless CMS. Así que no necesitamos trabajar con eso ahora mismo. Y hay componentes. Los componentos van a ser la parte más importante de la masterclass de hoy. Así que voy a repasar todos esos en mayor detalle, solo para que sepas, este es el código que vamos a estar editando. Y estos son los componentes que vamos a estar añadiendo aquí justo antes del final de la etiqueta de cierre de la tabla. Sí. Así que este es el lugar donde siempre vamos a añadir uno y ver si funciona en el front-end. Así que ahí está el design de la masterclass. Esperemos que todos estemos aquí. Así que eso sería casi todo desde el lado del proyecto, creo, o puedo darles el ID del ambiente también. Así que si quieres ejecutar las funciones localmente, esto es lo único que necesitas en tu archivo de ambiente. Sí. No se necesita nada más. No se necesita la clave de la API. Es solo para generar los modelos, pero los modelos ya están ahí. Marco está comprobando si habrá una grabación. Sí, habrá una grabación. Así que si te estás perdiendo algo, no te preocupes, siempre puedes volver. O puedes enviarme un mensaje. Lo explicaré. Con gusto. Así que esos son los fundamentos de la solución. Ahora, esta es de nuevo la dirección URL donde las funciones están implementadas. Ya están funcionando, así que están obteniendo los data del CMS, y ya envié esto en la ventana de chat, así que deberías ser capaz de simplemente copiarlo y pegarlo. Bien. Y eso me lleva a la primera parte de la masterclass. Así que, la masterclass tiene un título Data Fetching Strategies. Ahora, hay dos significados diferentes de la obtención de data en las aplicaciones de Scobo JavaScript. Y el primero es el real, como, esto es lo que siempre imaginamos, ¿verdad?, cuando hablamos de la obtención de data, es siempre la aplicación React creando una solicitud a la API, la API devolviendo data. Pero en realidad, se ve un poco más así. Así que, la aplicación React normalmente tiene muchas características, normalmente tiene un diseño, normalmente tiene algún tipo de almacenamiento que usas para almacenar data y para almacenar el estado en el lado del cliente, ¿verdad? Cuando quieres trabajar con componentes. Y cada componente necesita tener un data diferente, pero solo lo obtienes una vez y así sucesivamente. Así que, el almacenamiento normalmente está ahí. Y tú ves que el almacenamiento está comunicándose con las características. Algunas características están realmente obteniendo los data en el almacenamiento. A veces el almacenamiento está obteniendo los data de la API por sí mismo. Así que, es bastante complicado. Incluso para aplicaciones simples, normalmente es bastante complicado. Y ves algunos componentes incluso obtienen los data fuera del almacenamiento. Así que, en este caso es el diseño que solicita los data de la API. Por supuesto que puede haber múltiples APIs que normalmente hay. Así que, en el alcance de esta masterclass, quiero dividir esto en dos grupos. El primer grupo es sobre la solicitud real y los data. Así que, cuando tenemos un componente, tenemos un almacenamiento, tenemos una característica. No nos importa. Se trata solo de obtener los data del punto final y obtener el JSON o los data que queremos. Esta es la primera parte. Y para esa primera parte, esto es por supuesto lo mismo, sí, cuando el diseño se comunica con la API directamente.

Así que, hay una pregunta. ¿Quisiste decir, como la URL mencionada, esto está mostrando un error de página no encontrada? ¿En serio? Debería ser esa URL. Creo que tienes una barra extra ahí. Si vas a APIs.Flights, va a ser data. Así que, ¿puedes probar esto?

Oh, está bien, ahora funciona. Así que tal vez solo Axios era un problema. Ahora parece que funciona. Por supuesto, no está obteniendo ningún data. Así que déjame comprobar qué está mal. Oh, origen cruzado, está bien. Eso es un poco de problema. Está bien, en ese caso, si realmente puedes ejecutarlo localmente, sería más fácil porque eso eliminará la necesidad de hoarse en este caso. Así que si puedes ejecutarlo localmente, entonces creo que puedes simplemente ejecutar Netlify dev y cambiar la llamada a slash API slash get flights. Y eso debería darte resultados localmente. Déjame comprobar eso rápidamente.

Luego, no. Estimando inesperadamente, está bien. Déjame intentar esto de nuevo. Está bien, ahora tenemos problemas con otro componente, React query y SWR. Así que necesitamos comentar esos también. Sí. Veré si funciona localmente. Cuando funciona localmente, vamos a intentar y arreglar el error en el remoto. Ahora, todavía hay algunos problemas. Déjame intentarlo de nuevo. Está bien. Está bien, ahora esto funciona. Está bien, así que si puedes ejecutarlo localmente, entonces eso es lo más fácil. Así que simplemente crea un archivo de entorno con esto. Voy a pegarlo en el chat. Sí, también puedes hacerlo en un tsconfig, pero vamos a tener que usar esos archivos más tarde de todos modos. Así que creo que esto funcionará. Así que localmente, esto debería funcionar. Si haces esto con el archivo de entornos, esto debería funcionar. Con Netlify dev, si puedes hacerlo localmente, entonces déjame comprobar si realmente podemos ejecutarlo con CORS. Así que deberíamos poder hacer eso aquí. Está bien, voy a tener que comprobar rápidamente. Así que no recuerdo eso de memoria. Sí, creo que necesitas hacer eso. Sí, Netlify CLI. Es como NPMI. Creo que es netlify y "-g". Algo así. Eso debería funcionar. Y déjame comprobar rápidamente. ¿Cuál es la notación de fetch course? Así que no recuerdo eso de memoria, pero deberíamos poder encontrar eso bastante rápido. Aquí está. Y veamos si eso realmente va a ayudar. Había un modo course. Solo un segundo. Y veremos si las funciones de netlify realmente permiten eso. Creo que deberían. Lo veremos en un segundo. No, no le gusta eso. Control de acceso permitir origen. Está bien. Está bien. Así que voy a tener que hacer un paso más aquí. Y déjame hacerlo en otro lugar. Así que tengo que ir a netlify para ver. Así que instalando y ejecutando un desafío con fetch devuelve los data de él. Perfecto. Muchas gracias por la confirmación. Justo ahora estoy trabajando en hacer las funciones de Netlify compatibles con course. Creo que esto debería hacer el truco, pero realmente tengo que empujar eso. Así que si has estado ejecutando, entonces dame un segundo. Solo voy a intentar resolver eso para todos. Está bien, así que se está desplegando ahora. Debería estar funcionando en un segundo. ¿Alguien depende del punto final remoto o ustedes lo tienen ejecutando localmente? Háganme saber si alguien quiere ejecutarlo remotamente. Sí. Está bien, perfecto, no hay problema. Debería estar allí en un segundo.

Bien, ahora está desplegado. Así que deberíamos estar listos para continuar. Veamos. Así que tenemos más CORS. Cerramos esto y comprobamos. Bien, probablemente tenga que, oh está funcionando. Puerto 3000. Bien, aún no funciona. Veamos. Bien, eso debería funcionar para la configuración de CORS. Sí, la configuración de CORS en un fetch es bastante fácil, solo proporciona aquí, pero ahora tenemos que habilitarlo también en el lado de Netlify. Y por alguna razón no está devolviendo el CORS. Estos son los encabezados correctos. Déjame comprobar eso en Postman en un segundo, por un segundo.

Sí, no está haciendo eso. Si hay alguien con las funciones de Netlify con conocimientos extensos, entonces avíseme si realmente lo estamos haciendo bien. Así que hice esto, pero no parece funcionar para las funciones. Oh, creo que también necesitamos hacer esto para las redirecciones. Quizás ese sea el problema. Redirigiendo desde el destino original. Así que déjame intentar eso de nuevo. Y con suerte eso resolverá todo para nosotros. Ahora, estoy desencadenando otro despliegue. Así que con suerte esto funcionará ahora. Déjame reiniciar esto. Y parece estar publicado, así que con suerte esto funcionará. Veamos. No. Me está mostrando problemas de CORS. Bien, ¿todavía hay alguien... QueenKey, veo tu mensaje. ¿Hay alguien más que necesite tener el punto final remoto? No puedo hacer que funcione de esta manera. Y no sé por qué porque debería funcionar. Un último intento, voy a probar la API. En lugar de la API, voy a probar la URL completa. Pero de lo contrario, esa es esta parte. Sí, voy a intentar esta URL. Veamos si eso ayudará. Sí, todavía me está mostrando problemas de CORS. Y no sé por qué, honestamente, porque aquí tenemos todos los encabezados hechos. Si hay alguien que ve lo que estoy haciendo mal, avíseme. Quizás hay algo que no estoy viendo aquí. Pero hasta donde veo, esto debería funcionar. Y mira, en realidad está funcionando. Así que la función no es realmente como, sí, veamos. Sí, esto es lo que intenté, en realidad. Esto es lo que intenté. Eso es exactamente lo que tengo allí. Pero por alguna razón, no está funcionando. Mira, es exactamente esta parte. Siempre son los problemas con CORS. De todos modos, creo que vamos a seguir adelante. ¿No deberías usar la URL de localhost en React? En la parte inferior dice que hicieron una comprobación de opciones en la función misma. Bien, déjame ver. Entonces lo que hicieron es que devolvieron los encabezados con el código de estado y data. Bien, eso es algo que realmente quiero evitar. Así que lo hicieron aquí, bien. Bien, podemos intentar hacerlo. Un último intento, luego vamos a seguir adelante. Así que déjame comprobar eso. Y guardemos eso. Lo voy a intentar en un punto final y veremos si funciona para los demás también. Bien, está construyendo ahora. Deberíamos ver en un segundo. Y bien, encuentra. Por supuesto, ahora podemos volver a la API. Bien, ahora está en vivo. Veamos. Bien, aquí vamos. Eso funcionó.

Entonces, ¿pueden ustedes, o Pingy, por favor verificar que ahora funciona para ustedes? Es el punto final de obtener vuelos. Sí, es glorioso. Perfecto, está bien. Depuración en vivo, siempre es divertido. Perfecto, ahora que tenemos el fetch en marcha, esperamos poder avanzar. Así que permítanme cerrar esto. Cierren eso también, y cierren este. Así que tenemos el fetch aquí. Y en TSX tenemos el fetch aquí también. Ahora, déjame ver, ¿qué podemos hacer a continuación?

Lo siguiente es Axios. Correcto, esta es la forma más básica de obtener data de un punto final remoto. Por supuesto, con Axios obtienes un poco más de opciones. Oh, solo cierra esto. Obtienes un poco más de opciones, principalmente en términos de interceptación de solicitudes y respuestas. Así que a veces sucede que cuando estás construyendo las URL, estás construyendo el objeto de opciones, estás combinando modos, estás combinando data y así sucesivamente, y algo no funciona, entonces Axios realmente te da buenas opciones para la interceptación de solicitudes y respuestas. Lo veremos en un segundo. Te da opciones para el tiempo de espera de respuesta. Ahora, por supuesto, esto también es posible con Fetch API, pero de una manera mucho más complicada. Así que con Axios, solo defines cuál es el tiempo de espera, y se cancelará en ese momento. También te permite aplicar una política de reintentos. Así que cuando una solicitud vuelve con un problema o se pierde o algo así, entonces Axios te permitirá reintentarlo y tiene soporte para navegadores más antiguos. Es por eso que cuando estás trabajando con servicios SUS y te dan sus SDKs o algo así, normalmente los ves usar Axios porque proporciona la mejor compatibilidad para los navegadores más antiguos, porque Axios se basa internamente en solicitudes XML HTTP. Eso es un poco de cereza en la parte superior, pero te permite... Te da una transformación automática de datos JSON. Así que no tenemos que hacer el await.json, pero lo hace automáticamente. Eso me lleva a otra tarea y eso es lo mismo que hicimos hasta ahora. Eso es un componente Axios TSX. Esta es solo la línea única que obtiene todos los vuelos. Así que vamos allí. Ahora renombra eso de nuevo a Axios.TSX y agrega la llamada aquí. Así que lo que realmente queremos hacer es await Axios.get y usar la misma URL. Así que ya sea api slash api slash getFlights o la URL de Netlify. Ya no lo tengo en el portapapeles. Así que solo voy a copiar y pegar desde aquí. Así que OOTB significa Out-of-the-box. Lo siento por eso. Así que fuera de la caja. Así que eso significa que no tienes que resolverlo de todos modos. Como con fetch API, tuviste que hacerlo con los polyfills. Con Axios obtienes eso por defecto. Así que veamos Axios.get Y tenemos que hacer los corchetes una vez más porque estamos obteniendo todo el objeto. Solo queremos los data y estamos configurando los vuelos. Así que guardemos eso. Y no olvides volver a App TSX y cambiar el fetch por Axios. Y asegúrate de que la importación es components-Axios. Así que probablemente va a querer algunas importaciones en los archivos también. Ya los tengo allí. Pero si necesita algunas importaciones, entonces solo asegúrate de tenerlas. Y eso realmente compila, pero debería funcionar. Ahora, veamos, no se encontraron problemas. Me gusta ver eso. Y veamos, oh sí. No está funcionando. De nuevo, por supuesto, creo que si estás trabajando de forma remota. Así que necesitamos agregar el modo de curso aquí también. Así que probablemente vamos a necesitar el modo aquí también. Por supuesto. Oh, déjame revisar. Google siempre sabe la respuesta. Así que estas son prácticamente las mayores diferencias entre Axios y Fetch, que la sintaxis o la configuración es un poco diferente. Así que necesitas saber con qué estás trabajando, pero de lo contrario, proporcionan prácticamente las mismas funcionalidades. Aunque Axios tiene un poco más de características, es un poco más agradable trabajar con él, pero requiere un paquete adicional. Veamos. Interesante. ¿Por qué no está funcionando para mí entonces? Error de Axios. Oh, 404. Eso es algo diferente. Obtener vuelos. De hecho, me falta una letra. Veamos.

Bien. Vale. Interesante. Pero lo bueno es que no está funcionando. Así que eso es bueno. Esa es la parte de Axios. Pero vamos a entrar en algo un poco más interesante. Así que si está funcionando para todos. Si no está funcionando, entonces avísame. Si está funcionando para todos, entonces vamos a por la siguiente tarea, que es interceptar solicitudes. Este código en realidad hace que Axios añada un interceptor antes de que atienda la solicitud. Y lo que hace es que en realidad comprueba todas las solicitudes y registra en la consola que la solicitud fue enviada por Axios a una URL específica. Así. Esto interceptará todas las solicitudes. También nos permitirá ver cuándo se disparó cada solicitud en la red. Cuando lleguemos a SVR, cuando ahora mismo solo estamos haciendo solicitudes, entonces también vamos a trabajar con la caché. Así que esto es beneficioso para ese caso también.

Así que aquí estamos usando los interceptores y usando una configuración que nos proporciona la URL. Y en caso de error, simplemente vamos a rechazar esa promesa y devolver el error. Así que este es el componente Axios intercept. Y voy a intentar hacer lo mismo. Así que, lo haré allí. Así que quieres ver Lucy, ¿Quieres ver el Axios.tsx? Claro. ¿Qué parte quieres ver? ¿Está bien? Aguanta un minuto. Claro. No hay problema. Así que el otro componente está justo debajo de él. Es axios intercept.tsx. Voy a cambiar allí en 20 segundos. Perfecto. Vale. Perfecto. Vale. Ahora podemos ir aquí, así que ya hay el comentario en el formulario interceptado aquí. Así que eso es lo que vamos a hacer. Así que los interceptores de axios. Queremos interceptar la solicitud. Creo que el uso y la configuración Y podemos simplemente devolver la configuración, sí. Así que esto es lo que estamos haciendo en realidad. Como estamos obteniendo las solicitudes y estamos devolviendo la solicitud si no queremos cambiar nada. Si hay algo que queremos hacer, como queremos hacer el console.log. Podemos hacer eso. Y ves que con la configuración, obtienes todos los detalles de la solicitud. Tienes los encabezados. Creo que en algún lugar también obtienes los data y ahí está la URL. Así que queremos obtener la URL y devolver la configuración. Y por supuesto, la siguiente parte es opcional. Como si quieres hacer el error, este es el manejador de errores. Así que está aquí para el caso en que quieras interceptar el error también. En este caso, solo estamos devolviendo el rechazo de la promesa. Y podemos proporcionar la razón. Y eso es todo realmente. Si guardas eso y de nuevo, cambias los componentes en el app TSX, deberías poder ver este mensaje cada vez que te refieres a la página porque solo hay una solicitud por página ahora mismo. Así que déjame hacer eso, Axios intercept, y va a añadir la importación automáticamente. Ahora cuando vuelvo a la URL, vale, estoy obteniendo errores. API y déjame arreglar eso. Vale, ahora obtenemos los data aquí y en la consola, también ves solicitudes y las URLs slash API slash get files. Creo que esto es anterior. Aquí tenemos la URL completa. Así que ves a qué URL se envió la solicitud. Así que ves una vez por página. Por supuesto, está la advertencia, cada hijo en la lista debería tener una prop clave única. Realmente no me centré en el front-end, pero si quieres, puedes simplemente añadir la clave aquí, ID del sistema por ejemplo, y se va a deshacer de ese error. Dame como medio minuto. Luego vamos a pasar a la siguiente tarea. De vuelta al entrenador, seguro, no hay problema. Así que este es el código. En realidad está bajo xus.interceptors.request, y está usando la configuración. De nuevo, esto es solo un objeto que puedes cambiar en su camino al servidor remoto. Todos los derechos.

Espero que hayamos terminado. Por alguna razón, obtuve cuatro bloqueos. Así que si tienes el problema con la clave, acabo de solucionarlo. Esa era esta parte, pero no es algo de lo que debas preocuparte en este momento. Nos estamos enfocando en hacer el interceptor no en afinar el front end. Es una buena práctica tener la clave allí para que no tengas que volver a renderizar todo cada vez. Pero no es algo que impida que los data lleguen.

Hay un comentario a la derecha. Oh sí. No, lo obtenemos tres veces. Eso es interesante. Veamos. Debe haber algo con el React performance. Sí. Pero aquí, en realidad no estoy seguro de por qué obtuvimos tres de ellos. Sí. Sí. Añadamos eso allí. Hagámoslo. ¿Todavía lo estamos haciendo tres veces? No lo sé. No sé por qué. Pero no debería hacer la solicitud tres veces. Debería hacerlo solo una vez. De todos modos, tal vez lo descubramos más tarde. Sí, estamos en un modo estricto. De todos modos, pasemos a otra tarea. Veamos si eso mejora más tarde.

Lo siguiente que está preparado para nosotros es la política de reintento. Ahora, hay un componente llamado AxiosRetry. Esta no es la mejor manera de manejar los reintentos, y vamos a ver SVR más tarde porque es mucho más fácil de implementar. Pero con Axios, en realidad hay una biblioteca, ya está instalada, si instalaste todos los paquetes de npm, llamada AxiosRetry. También hay una forma de manejarlo a través de los interceptores. Entonces, si interceptas la solicitud y en realidad proporcionas una función aquí en lugar de error y haces el reintento allí, también es posible manejarlo aquí. Sin embargo, cuando hay una biblioteca, ¿por qué lo harías por tu cuenta, verdad? Entonces, el AxiosRetry ya está en tu proyecto, por lo que puedes usar simplemente el AxiosRetry y definir cuántos intentos quieres que Axios reintente la solicitud. Y hay un retraso de reintento. Ahora, normalmente, la mayoría de las bibliotecas por defecto lo harían de manera que reintentan la primera solicitud, luego esperan unos segundos, y en realidad duplican la cantidad de tiempo que esperan para ahorrar recursos. Entonces, eso es lo que es el AxiosRetry.exponentialDelay. Entonces, eso está haciendo exactamente eso. En este caso, en el archivo AxiosRetry, verás que estamos usando otra función aquí. Entonces, como el getflight's es poco fiable, si estás trabajando localmente, eso va a funcionar. Si no estás trabajando con el punto final local, lo voy a arreglar en un segundo, pero este es el punto final que te mostré antes que devuelve una buena respuesta solo una vez cada cinco veces. Entonces, adelante e intenta hacerlo allí. Voy a agregar el código aquí. Entonces, este es el AxiosRetry, y necesita la instancia de Axios, por supuesto, y luego necesita la configuración. Entonces, vamos a hacer 10 reintentos y retraso de reintento. Oh, retraso exponencial. Y eso debería ser todo lo que necesitas hacer aquí. Entonces, solo guarda eso, y déjame arreglar el punto final para que también podamos probar este. Genial. Bien, así que ahora está construyendo. En un segundo debería estar disponible. Ahora déjame copiar la URL. Entonces, ¿se agrega esta configuración globalmente para todas las solicitudes o solo para la actual? Esa es una buena pregunta, en realidad no estoy seguro. Podemos probarlo, sin embargo. Podemos probarlo, podemos agregar otro use effect aquí. Y ver si hace lo mismo. Fresh data dos, obtenemos vuelos. Oh, pero esto será un poco, oh, esto no es ideal. Déjame probarlo en el otro. Entonces déjame probar si esto funciona primero, luego vamos a probarlo con el registro de la consola eso sería más fácil. Oh, y por supuesto olvidé cambiar el componente. Entonces también necesitamos cambiar el componente aquí de Axios intercept a Axios retry. Oh sí, eso tiene sentido. Binging. Entonces, y ahora no está funcionando. ¿Por qué no está funcionando? No está funcionando el curso, pero ya cambié eso. Así que debería funcionar, pero de todos modos, ves que realmente está intentando, sí. Get flights unreliable debería tener todos los encabezados correctos. Get flights unreliable, pero todavía se queja. Oh, ahí está, no, no necesitamos eso aquí.

Hmm. Sí, exactamente. Entonces puedes ver que está esperando más y más y más. ¿Configuras la respuesta del curso para todos los puntos finales? Lo configuré para este de nuevo. Obtener vuelos poco fiables. Sí. Acaba de hacer eso. Ahora. Déjame intentar y desplegarlo de nuevo. Así que edité los encabezados para los vuelos obtenidos. Ahora hice eso para olvidar los vuelos poco fiables. Ahora estoy intentando volver a desplegarlo. Veremos si eso ayuda. Pero debería funcionar. Ah, pero no lo hice para, correcto. Bueno, ahí está el problema. Así que hice eso. De hecho, echemos un vistazo a la función para que puedas evitar el mismo error. Así que agregué los encabezados aquí para el código de estado 200 pero no los agregué aquí para el 500. Ese sería el problema. Bueno, debería estar en funcionamiento en unos momentos. Y déjame mostrar el código de nuevo. Vale. Así que ahora está publicado, veamos. Vale, esto es mucho mejor. Así que ves que estamos obteniendo errores, pero sigue intentando obtener los data, y finalmente al final obtenemos los data aquí. ¿Está funcionando para todos? Háganme saber en el chat si funciona para ustedes. Espero que eso sea perfecto, lo hace. Genial, bien, genial. Muy bien, así que ese es el reintento de Axios, y veamos. Hay una última tarea aquí. Intenta usar el componente / axios-timeout. Ahora no hay tarea para ti en ese componente para ver la solicitud en realidad tiempo de espera. Entonces, cuando miras el componente axios-timeout, lo único que hace es que tiene un tiempo de espera de dos segundos y un mensaje de error de tiempo de espera para el tiempo de espera, y está utilizando el punto final de la API obtener vuelos lentos. Ahora eso solo funcionará localmente. Así que no agregué encabezados para eso. Déjame arreglar eso en un segundo, pero de nuevo, solo para intercambiar los componentes en el AppTSX y todo debería funcionar para ti.

Muy bien. Vale. Acabo de ajustar todos los endpoints, así que ahora todos deberían estar funcionando también de forma remota. Veamos. Permíteme volver a AppTSX y cambiar eso. Tiempo de espera de XU. Y. Y por supuesto necesito cambiar el endpoint al remoto. Esto es más o menos lo que esperamos. Sí, error de excusa, manejo de tiempo de espera, se agotó el tiempo por lo que no vemos si no vemos nada. Tendríamos que manejar el error de alguna manera para proporcionar un mensaje más agradable pero lo importante es que no estamos viendo CORS aquí. Parece que funcionó y el tiempo de espera realmente lo impide de obtener los data. Si realmente lo hacemos más, digamos 10 segundos, debería empezar a funcionar. Guardé eso. Sí, ahí está. Así que simplemente desperdicia cinco segundos y luego nos da los data. Vale, así que eso fue lo último aquí, una especie de cosa extra. Y ahora podemos pasar a la parte más interesante de la obtención de data, y esa es esta parte. Esa es la gestión de data. Si quieres manejar los data usando un store, eso es por supuesto posible, pero las bibliotecas de las que vamos a hablar, usan VR y React Query, en realidad manejan todas estas cosas por ti. En caso de que tus componentes necesiten obtener los data y no quieras manejar eso explícitamente, puedes usar estas herramientas para manejar eso. Así que obtener y manejar los data, hasta ahora siempre usamos useEffect. No sé si te diste cuenta de eso, pero siempre estuvo aquí. Esto significa que cuando el componente React se monta, esto realmente llamará a lo que sea que esté dentro solo una vez, porque hay un área vacía como dependencias. Así que solo ejecutará esto una vez, pero lo hará de una manera un poco incómoda, diría yo. Con useSVR, esa es la otra opción que tenemos aquí. Mejora mucho porque fue diseñado, es en realidad una biblioteca que está implementada o desarrollada por Vercel, y es SWRS en estado mientras se revalida. Y proporciona, está realmente enfocado en la obtención de data, por lo que te da todos los estados de estado y todo lo que necesitas para también react en diferentes estados de la carga de data. También vamos a usar use query más tarde, pero primero quería echar un vistazo a still mientras se revalida, cómo funciona en realidad. Conseguí esta imagen de Google, porque tienen diagramas realmente geniales en este sentido. Y esto muestra muy bien cómo funciona still while revalidate. Así que en primer lugar, cuando estás solicitando algunos data de la página, intenta encontrar eso en la caché. Así que no está haciendo la solicitud de red, si lo encuentra allí, lo proporciona de vuelta a la página y lo revalida en segundo plano. En este caso, cuando los data, por supuesto, cuando nos referimos a la página, los data no están en caché. En ese caso, hacemos el viaje de ida y vuelta al servidor, luego lo almacenamos en caché y luego lo proporcionamos a la página. Así que de alguna manera ahorra las solicitudes posteriores. Y también asegura que cuando tienes varios componentes que necesitan los mismos data, pueden o el SVR puede hacer la solicitud de red solo una vez y luego dejar que los componentes compartan los data recogidos. Así es como funciona el SVR. Es el mismo principio que con los react threes. Sí, también almacenan los data localmente. Por supuesto, más tarde podemos hablar de cómo mutar los data, cómo refrescar los data, cómo revocar proactivamente la validez de los data y así sucesivamente. Pero primero quería repasar las características de SWR. Como mencioné, SWR es una biblioteca. La instalas en tu proyecto y la usas en lugar de useEffect. Así que podemos comparar useEffect con USE-SWR. En SWR en caso de obtención de data gana en todos los puntos. Creo que proporciona un manejo más fácil de los estados de carga y error. Así que te da los diferentes estados en forma de booleanos para que podamos proporcionar diferentes front ends para cada uno de esos estados. Tiene una fácil configuración de política de reintento. Vamos a verlo en un segundo, pero es mucho más fácil que con Axios y con los interceptores. Proporciona la deduplicación de solicitudes. Eso significa que cuando estás cargando varios componentes en una sola página que necesitan los mismos data, solo hará la solicitud de red una vez. Proporciona características para la interacción automática basada en intervalos basada en la interacción o no revalidación. Eso significa que por defecto cuando vas a otra pestaña y luego vuelves a tu página, puede revalidar los data automáticamente. También puede react en muchos otros eventos que ocurren en tu aplicación. Pero como mencioné aquí, puede ser automático, puedes definir un intervalo cuando la revelación debería tener lugar o puedes prevenir la revalidación en general. Así que dependiendo de lo que necesite tu proyecto. Y luego tiene la capacidad de hacer paginación y precarga. Maneja eso de una manera muy, diría yo, fácil y simplista. Que lo que hace React Query, por ejemplo. Pero veremos eso en un momento. Un buen beneficio es que su paquete es relativamente pequeño, solo 4.4 kilobytes. Mucho mejor que lo que vamos a ver para React Query. Pero en general, he oído de los desarrolladores que esta es típicamente la forma de ir porque proporciona todas las características necesarias para un paquete realmente pequeño, pequeño. Pero vayamos a la siguiente tarea para que podamos ver cómo funciona en la realidad. Así que, vamos a usar el hook useSvr en lugar de useEffect. Y el buen punto aquí es que para el useSvr y para el React Query, vamos a hablar de eso en un momento, siempre necesitas usar ya sea Fetch API o Axios, ¿verdad? Así que, no va a hacer la solicitud en bruto por ti, pero tienes que proporcionar una función de fetch, la llamada función de fetch, que realmente obtendrá los data. Así que, no le importa cómo estás haciendo la solicitud de red, está en tus manos, pero tienes que proporcionarlo de alguna manera. Así que, vamos a usar el hook useSvr en lugar de useEffect. Y vamos a ver cómo podemos mejorar la vista para los estados restantes.

Entonces, ves que es, la llamada parece useSvr. El primer parámetro es una clave de los data. En la mayoría de los ejemplos que ves en línea, vas a ver, lo siento por eso. Vas a ver aquí una ruta de API. No confundas esto con la función fetcher. Esto no significa que va a obtener los data de esa ruta. Aquí, solo estás proporcionando una especie de identificador para los data, solo una clave. Y la función fetcher de vuelos será una función que toma los data y los proporciona.

Entonces echemos un vistazo al SWR. Bueno, este también tiene algunas especificaciones, así que eliminemos eso. Y ves que lo primero es la función fetcher de vuelos aquí. Y es una función async. De lo contrario, se ve exactamente igual que antes. Estoy usando fetch aquí, lo que significa que también voy a tener que agregar aquí el modo CORS. Y proporcionar el punto final. Si quiero usarlo de forma remota. Pero de lo contrario, ves, es exactamente lo mismo. Estamos devolviendo los data, estamos haciendo un console log aquí, obteniendo data desde el punto final remoto, para que podamos ver que solo está haciendo eso una vez. Y aquí necesitamos hacer la llamada SWR. Así que será use SWR. Como mencioné, primero es la clave, así que pueden ser vuelos. Puede, por supuesto, también ser /API/vuelos. Si quieres unificar eso, Yo consideraría eso una buena práctica. Tener eso igual que hace la función Fetcher, pero está completamente a tu discreción. Así que hagamos todos mis vuelos aquí. Y aquí necesitamos la función Fetcher. Así que Fetcher de vuelos. Y, por supuesto, de esta manera no obtenemos los data de ninguna manera. Así que necesitamos, podemos hacerlo de esta manera. Así que podemos llamarlo como info. Y tenemos todos los data aquí en la constante info, pero lo que también podemos hacer, podemos desenrollar esto y decir que queremos data, queremos su carga, y queremos estados de error. Sí, de lo contrario todo está en el mismo objeto. Así que si lo haces de esta manera, o si haces info, y luego haces info.isLoading, completamente a tu elección, prefiero hacerlo en un paso. Así que hagámoslo de esa manera. Así es como realmente obtenemos los data.

Ahora, lo bueno aquí es que solo tenemos la tabla aquí, y siempre estábamos esperando solo para que los data aparezcan. Lo que podemos hacer ahora es decir, si isLoading, podemos devolver algo como, así que estamos devolviendo tBody aquí. Así que probablemente queremos hacer eso para que el marcado HTML sea el mismo. Tienes cinco columnas. Y solo vamos a poner aquí algo como cargando datos. Y lo mismo se puede aplicar al error. Luego giramos tBody. Solo copiamos y pegamos eso para no tener que escribir todo. Está bien. Y la última parte como de costumbre, vuelve a aptsx y cambia eso. Así que aquí queremos usar swr de componentes. Y veamos. Falló al cargar los data, mira eso. Obteniendo data remotos desde el punto final. Por alguna razón no, como... Déjame ver cuál es el problema. Oh sí, este es el problema. No, estamos en el archivo equivocado. Modo de búsqueda swr CORS. Tenemos clientes que deberían funcionar. Obteniendo data desde el punto final remoto. Lo conseguimos aquí. ¿Por qué estamos usando swr retry? Usando swr. Oh, está bien. Tengo una importación incorrecta allí. Debería ser solo swr. Y hay un error en el archivo de reintento. Debería ser reintento. Bueno, ahora veamos si guardamos eso. Bueno, finalmente, obtenemos los data. Y eso es todo. Ves, si refresco la página, ves que está cargando data, luego obtengo los data de inmediato. Y también viste que si no puede obtener los data desde el punto final, automáticamente está aplicando la política de reintento. Así que aquí ni siquiera tienes que configurarlo. Está funcionando por defecto de esa manera.

Ahora, por supuesto vamos a ver el reintento en un segundo también, en caso de que quieras cambiar el comportamiento. Pero en general, esto debería funcionar así. Sabes que cuando estaba cambiando o cuando estaba usando el Use as VR, también agregué el modo CORS. Así que si estás usando el punto final remoto, está usando el fetch. Así que el fetch necesita el modo CORS aquí para obtener los data. Puedes simular la conexión de red lenta en Chrome, supongo que Firefox tiene esa característica en la pestaña de red.

Sí, definitivamente. Sí, podemos hacer eso. En este caso, no estoy tratando de hacer eso. Aquí solo estoy tratando de usar el Use as VR. Y para los otros casos de uso, en realidad tenemos el otro, para mostrar el mensaje de carga de data. Sí, definitivamente. Sí. Puedo hacer eso. No estoy seguro de dónde está eso, pero supongo que está por aquí, digamos 3G regular. Siempre encuentro esto demasiado lento, pero bueno, tal vez sea por la imagen, pero ves aquí cargando data. Intentemos eso de nuevo. Sí, para un 3G regular, esto parece un poco lento. Ahí vamos. Sí, buen punto. Perfecto, así es como funciona el uso de SWR. En general, es mucho mejor porque viene con muchas de las características automáticamente. Sí, y es mejor que el use effect porque esto fue realmente diseñado para ese caso de uso específico. Así que en realidad me decantaría por este para cualquier obtención de data. Ahora, volvamos. Háganme saber chicos si todos pueden ver esto, si están en el mismo lugar o si necesitan más tiempo, si necesitan más tiempo, háganmelo saber. No estoy seguro si eso está bien. Pero espero que estemos bien. Vale. Flags fetcher llamando a unreliable en su lugar. Sí. En ese caso, ese fue el error que corregí aquí. Así que el archivo de reintento de SWR tenía SWR aquí solo. Así que si tu Visual Studio lo recogió igual que el mío, entonces tu importación en app.tsx está mal porque muestra aquí SWR retry. Así que voy a cambiar eso a componentes slash SWR. Sí, no nombré el reintento, por supuesto. Sí, eso es lo que hice, en realidad. Vale, usando SWR ¿tienes que actualizar manualmente la clave si quieres que tu fetcher obtenga algo más? Diría que es una buena práctica hacer eso. Ahora mismo, ves que aquí en SWR, la clave no tiene ninguna relación con el fetcher de vuelos porque el fetcher de vuelos define su ruta por sí mismo. En el caso ideal, probablemente lo haría de esa manera. Y en la documentation, también ves la función fetcher como algo que es muy genérico que solo toma el argumento del primer parámetro y lo usa para la ruta también. Así que probablemente sería una buena práctica hacerlo de esa manera. Sí. Pero no es necesario. Al final, esta es solo la clave de caché.

Vale. Creo que podemos pasar a otra tarea. Esa sería la adición de etiquetas de estado para informar al usuario cuando se están obteniendo data o se produce un error. Así que esa es la siguiente parte que hice con las etiquetas. Y ves, es realmente fácil simplemente, si está cargando y devolver lo que quieres devolver es error lo mismo. Y lo último que quería probar es duplicar el componente en app TSX y comprobar que la solicitud de red ocurre solo una vez. Así que en realidad es muy fácil de probar si vuelves a app TSX y copias esto unas cuantas veces. Por supuesto, deberías verlo un par de veces, pero déjame borrar esto. Pero ves que la solicitud de red solo ocurrió una vez. Vale. Vale. Ahora, déjame saber si podemos seguir adelante con esto. Si lo has probado. Sí, ves que cuando me muevo entre pestañas, lo hace de nuevo. Así que cada vez que intento volver ahora, creo que mencioné el tiempo, pero cuando voy aquí, aquí, ves, está volviendo a buscar eso. Así que es bastante agresivo con la revalidación. Por supuesto esto puede ser configurado si quieres que se comporte de manera diferente. Muy bien, así fue la tarea cinco. Ahora la tarea seis es mutar el SWR. La función mutate en caso de SWR puede invalidar los data en caché. Cuando miramos el botón en el componente SWR mutate, solo necesita ser, solo hay un único botón, botón HTML, y necesitamos hacer el evento onclick para mutate files, así que esa es la función mutate aquí. Y cuando hacemos eso, cuando proporcionamos la clave de caché o el identificador de los data en caché, en realidad eliminará los data de la caché y forzará su revalidación. Así que echemos un vistazo. Está en los componentes SWR mutate. Así que aquí está el botón.

Ves que este es el componente funcional que solo tiene el botón, nada más. Permíteme ponerlo aquí para que sea un poco más visible. Y permíteme poner el onClick aquí. Entonces, lo que queremos hacer es mutar los vuelos. Y añadir la entrada de SWR. Y voy a editar debajo de la tabla para que podamos ejecutar esto. Todavía voy a eliminar los componentes extra allí y añadir el botón aquí. Era el swr-mutate. Vamos a eliminar todo eso y refrescar la página.

Bueno, así que obtuvimos los data del punto final remoto. Y cuando revalido, ves que está obteniendo los data de nuevo. Automáticamente, sí, porque todavía necesitamos tener los data aquí. Entonces, ¿qué pasa si usamos eso en diferentes niveles de componentes? Es decir, cuando uso el fetch-in app y también lo llamo en subcomponente, ¿pero también solo fetch una vez? Sí, en ese caso, solo hará fetch una vez. Eso es en realidad lo que se llama, volvemos aquí unas cuantas veces. Oh, ¿dónde estaba? Alexios, características de SWR, aquí está. Eso se llama deduplicación de solicitudes. Eso significa que si ambos componentes necesitan los mismos data y los piden, solo los buscará una vez. Sí, eso es lo que simulamos en la página principal cuando añadimos el componente unas cuantas veces. Y vamos a borrar eso y pulsamos el botón Revalidar. Ves que está obteniendo data del punto final remoto solo una vez, pero tenemos tres componentes aquí que realmente necesitan los data y que están intentando proactivamente obtener los data del punto final de la red, pero, ves, solo lo hace una vez.

Entonces, ¿el mutate recibe dependencias de fetch como parámetros? ¿A qué te refieres con eso? Sí. Entonces, cuando volvemos a swr.mutate, este es el evento onClick que añadí. Así que está mutando y solo los vuelos. Así que esta es la dependencia o esta es la clave bajo la cual los data están en caché, y va a revalidar después de eso. Todo bien, perfecto. Entonces, cuando volvemos aquí, creo que esto es lo que ya hicimos. Prueba la política de reintento implementada en swr utilizando el componente swr-retry. Entonces... No entendí para qué se usa mutate. Correcto, en este caso, al llamar a mutate y la clave aquí, estamos diciendo que estos data que están almacenados en caché ya no son válidos. Así que cuando hacemos eso, cuando haces clic en eso, y cuando estamos mutando eso, en realidad está invalidando los data y los está buscando de nuevo, porque hay componentes que dependen de los data. Así que lo que hace es que le dirá a swr, estos data ya no son válidos, búscalos de nuevo. Correcto. Y ves eso justo aquí. Todavía está llamando a la búsqueda de data desde el punto final remoto. Así que vuelve al componente que usamos y está llamando al buscador de vuelos de nuevo. Por supuesto, hay advanced casos de uso donde puedes mutar los data también solo localmente y trabajar con ellos. También puedes usar el mutate para publicar data en puntos finales remotos y así sucesivamente. Desafortunadamente, no tengo un caso de uso para eso aquí en el alcance de esta aplicación. Pero esta es la forma más fácil de invalidar los data. Este es el caso de uso que quería mostrar. Pero de lo contrario mutate se usa para realmente mutar los conjuntos de data. Tienes que ajustar los data, cambiar los data, o incluso publicar los data o parchear los data, lo que puedas pensar. Este es solo un caso de uso muy simple que invalidará los data y hará que SVR llame a esto de nuevo. Y eventualmente rearender el componente a medida que obtenemos los nuevos data. Si esa solicitud tiene algunas dependencias que pueden haber cambiado, tal vez debería o no debería refrescar basado en esas dependencias. ¿Puedes manejar eso con mutate? Entonces en ese caso... Sí, depende de lo que necesites hacer. En ese caso, siempre volverá a buscar. Si llamas al mutate en esta clave, siempre invalidará y siempre causará que vuelva a buscar. Sí. Si quieres solo cambiar los data, No he visto ese caso de uso. Tendría que revisar la documentation para eso. Supongo que es posible. Pero sí, no lo sé de memoria honestamente. Tendría que revisar la documentation para ese caso de uso. Entonces, ¿mutate siempre fuerza la invalidación? En este caso, sí. Vale. Vale. Si hay algo más, no dudes en preguntar. Podríamos necesitar revisar la documentation, pero para eso está. Y luego el reintento de SWR. Realmente quería mostrarte eso rápidamente. Este componente está realmente implementado. Así que nada para nosotros que hacer aquí. Solo voy a cambiar el punto final. Y poner el CORS allí de nuevo. Y, vale. Entonces, lo que hace esto, y creo que también quería hacer los otros puntos finales para hacer el lento, o el poco fiable. Porque aquí estamos haciendo el reintento.

Sí. El poco fiable. Así podemos ver cómo funciona el reintento. Permíteme volver a la aplicación y cambiar eso aquí. Puedo dejar eso ahí. Entonces, cuando volvemos aquí, ves que falló al cargar los data. Y creo que el tiempo estaba ahí como cinco segundos. Así que cada cinco segundos está intentando acceder al punto final. Y una vez ves que todavía hay respuestas 500 una y otra vez, pero con suerte en un segundo vamos a obtener 200. Entonces, ¿el estado no ganó, verdad? Así que ahora obtuvimos los data. Así que ves que está intentando obtener como ahora mismo cambié en la implementación, cambié que está haciendo eso cada cinco segundos. Así que aquí configuramos cada cinco segundos. Probablemente podríamos intentar hacerlo de otra manera o simplemente dejar el comportamiento predeterminado, que debería hacerlo como vimos con Axios. Cada intento está tratando de prolongar el tiempo cuando está revalidando cuando lo siento, reintentando. Sí. Y ves de nuevo, volví a la pestaña y está intentando refrescar los data de nuevo. Ahora tuvimos un poco más de suerte. Cuando provocamos la revalidación de nuevo, ves que está intentando acceder al punto final de nuevo. Vale. Un intento más. Vamos a seguir adelante. Vale. 500 tal vez la próxima vez. Así que esa es la política de reintento.

Y esta es en realidad una tabla que quería mostrarte. La encontré en uno de los artículos y creo que ilustra muy bien las diferencias entre SWR y Use Effect y cuándo es realmente beneficioso usar uno sobre el otro. Así que ves que prácticamente la única ventaja de un Use Effect es que es parte del núcleo de React, lo cual SWR no es, pero en general SWR te proporciona características como caché incorporada, deduplicación de solicitudes, soporte SSR-ISR-SSG. Así que obviamente está construido por Vercel por lo que soporta todos estos modos de Next.js. Es capaz de revalidar en foco en recuperación de red. Así que eso es en realidad algo, si no tienes una buena conexión a internet, como la mitad de internet no está funcionando para ti, si todo el mundo estuviera usando esto, en realidad empezaría a funcionar, al menos parte de eso. Así que aporta muchos beneficios y es mucho, mucho mejor para trabajar también desde el punto de vista de la experiencia del desarrollador. Te proporcionaré la presentación más tarde, también hay un enlace para todo el artículo, una lectura muy agradable en realidad, así que definitivamente lo recomiendo. Y finalmente podemos llegar a React Query.

Ahora React Query es algo como use-as-w-are, comparten muchas de las mismas características, pero lo lleva a un nivel superior. Así que con use-as-w-are, maneja como el 80% de los casos de uso estándar de obtención de data. Con React Query, probablemente lo usarías para casos de paginación, desplazamientos infinitos y estos escenarios un poco más avanzados. React Query tiene una gran documentación pero en algunas cosas, también es realmente difícil de trabajar y conseguirlo, afinarlo para que esté configurado de la manera correcta. Así que definitivamente aconsejaría ir con use-as-w-are en la mayoría de los casos y usar React Query si necesitas características avanzadas y no importa si pasas un poco más de tiempo configurándolo. Pero en general, era conocido anteriormente como React Query ahora en la versión cuatro es una consulta de 10 stack. El buen beneficio es que no es sólo para React. Así que si trabajas también con Vue.js o si trabajas con Angular u otras plataformas o frameworks puedes usar la misma biblioteca allí también. Por supuesto no es el mismo código pero tiene sus alternativas, sí. Tiene más características. Hay un enlace, te enviaré la presentación, sí. Así que hay un enlace para las cuatro características más. Va en realidad a la documentación de 10 stack donde hay una bonita vista. Creo que este es el navegador equivocado. Permíteme... Permíteme copiar eso al otro. Donde compara la React query con todos los otros posibles frameworks que podrías usar. Y muestra bien donde están las características. Algunas características son más importantes que otras. También compara el tamaño del paquete que es definitivamente algo interesante. Sé que alguien mencionó el cliente Apollo así que ves que ese es un poco voluminoso pero es útil para GraphQL definitivamente. Así que sí, definitivamente un buen recurso. Lo siento por eso. También tiene reintento automático de solicitudes fallidas pero use-as-w-are también tiene eso. La configuración de esos es un poco más fácil aquí. Cuenta con cancelación de consultas lo que significa que si un componente es eliminado, si un componente es desmontado antes de que las solicitudes que disparó se terminen, React Query puede cancelar esas automáticamente. También hay data claros iniciales. Esto es muy útil si estás trabajando con generadores de sitios estáticos y quieres tener un, digamos que quieres tener un listado pero la primera página del listado quieres generarlos en el momento de la construcción. Y las otras páginas o si esto es un desplazamiento infinito y luego quieres cargar los otros data al hacer clic en un botón, lo haces en el lado del cliente pero los primeros los data iniciales pueden estar ahí desde el tiempo de construcción. Así que tiene estas características muy sofisticadas pero como mencioné, es al menos desde mi punto de vista, es mucho más difícil de configurar. Es en algunos casos como con el desplazamiento infinito que mencioné, es bastante difícil hacerlo bien con los tipos de TypeScript. Si estás trabajando con TypeScript extensivamente, no es fácil asegurarse de que todo cumple la notación que necesita React query. Así que sí, diría que me decantaría por use-as-w-are en realidad. El tamaño del paquete es de 13 kilobytes, nada que complicado diría como cuando los paquetes estos días tienen cientos de kilobytes. Así que no creo que este sea el factor más decisivo pero podría ser para alguien. Y vamos a la siguiente tarea para usar React query. Ahora no hice ninguna interacción, no estoy navegando por la documentación porque creo que el uso es bastante fácil.

Así que podemos hacerlo juntos, escribir en código. Ves que hay un componente llamado React Query ya preparado para ti. Y la llamada es prácticamente la misma que use as WR. De nuevo tiene is loading, is error, is refetching data constantes. Ves que el is refetching, ya te está proporcionando un poco más de data aquí. Así que con use as WR, sólo tenemos el is loading. Cuando era un refetching, todavía era is loading. Aquí podemos distinguir entre varios casos. Como el is loading es la primera vez, is refetching son las refetches posteriores. Y de lo contrario, de manera similar, la clave de consulta aquí, ves que sigue siendo la función de consulta de vuelos. Esto es de nuevo las características de vuelos. Así que necesitas usar Fetch API o X cos para hacer eso y así sucesivamente.

Entonces, echemos un vistazo al código. Así que esto es react query. Tienes que eliminar el sufijo y hacer eso aquí. Entonces, de nuevo, lo mismo que antes data. No estoy seguro de cómo se llama el resto. Así que voy a dejarlo como está ahora. Y vamos a usar useQuery.

Ahora para eso, vamos a necesitar usar la importación de fun stack react query, y veamos. Así que tenemos opciones aquí. Creo que la primera es la clave de consulta. Sí. Así que esto es en realidad un objeto, lo que necesitamos para proporcionar una clave de consulta, blanco. No veo esto como un array. Así que también tiene, no quiero entrar en eso porque está muy bien descrito en documentation, pero tiene la posibilidad de tener múltiples claves. Es en realidad determinista, así que puedes añadirlos en diferente orden. No en el array aquí, pero si haces esto, puedes añadir múltiples claves aquí en cualquier orden. Así que es mucho más granular de lo que ofrece UXSW R. Y creo que realmente necesitas hacer la función de consulta, que va a ser flightsfetcher. Y eso debería ser todo lo que necesitamos. Si no me equivoco. Ahora, por supuesto, no hay etiquetas aquí.

Así que ahora cuando tenemos useQuery aquí, deberíamos poder entrar en este sentido. Así que veamos si conseguimos eso. Sí, así que está cargando. Está refetching. Y creo que usamos error como estas claves. Así que de nuevo, igual que lo hicimos con SWR, estas dos etiquetas, podemos hacerlas aquí también. Así que está cargando error. Podemos hacer otro para, está refetching. Vale. Podemos hacer refetching data. Y por supuesto voy a tener que arreglar la búsqueda de nuevo. Y cambiar eso en app TSX. Vale. Intenta eliminar ese. Y ve la aplicación. No este, sino este. Vale, podemos hacer el throttling de nuevo. Regular 3G. Y refrescando. ¿Cómo es que no estás usando v5 de React query? Creo que no está en v5, pero podemos echar un vistazo. Sí, la consulta de time stack está en v4. Y antes se conocía como React query, pero esa era la versión 3, si no me equivoco. Veamos. Donde, leí eso en algún lugar. Quizás aquí. En algún lugar había una visión general que muestra eso, pero la v4 es time stack query. No creo que esté en v5. Sí. Vale. Vale. Entonces, sí. Así que aquí puedes ver que está haciendo la etiqueta de carga data. Vale. Vale. Esto está tardando demasiado. Vale. Aquí vamos. Así que estos son los data. Y cuando volvemos a la pestaña de nuevo, ves que era la re-fetching data. Ahora esto todavía es demasiado rápido, pero puedes ver que re-fetching data. Así que no está haciendo loading data, sino re-fetching. Así que tal vez podemos hacer GPRS, tal vez eso lo haga sí. Así que ahora re-fetching data. Sí. Así que obtienes la etiqueta correcta dependiendo de qué tipo de acción está ocurriendo en el fondo. Así que eso es todo. Y sí. Vamos a mantener las etiquetas para informar al usuario cuando data están siendo buscados, cargando re-fetched o ocurrió un error. Así que eso es lo que hicimos.

Espero que esto funcione para todos. Avísame si necesitas más tiempo. De lo contrario, podemos pasar a la última tarea. Tarea. Vale. Creo que estamos listos para continuar. Y la tarea en realidad no está aquí. La última es solo una pregunta sobre cómo elegir la mejor. Pero aún quería mostrarles una cosa más aquí con React Query. Y eso fue la paginación de React Query, que está en el componente justo al lado. Así que siéntete libre de echar un vistazo y agregarlo a la app TSX. Entonces, lo que hace es aparte de usar isLoading, isError, isRefetching, y así sucesivamente. También hay otra cosa muy cómoda isPreviousData. Así que eso es otra cosa de estado, ese booleano de estado, que podemos usar para mostrar u ocultar los botones de siguiente y anterior. Así que este ejemplo en realidad, el único cambio aquí es que proporciona un recuento total de data de getFlightsPaged. De lo contrario, sigue siendo la misma data, solo que la devuelve en función de una página y la devuelve a React Query. Ahora ves que aquí, en la clave de consulta, también estamos usando la página. Así que la página por defecto es cero, pero si la incrementamos con el botón, que está todo el camino aquí abajo, página más uno o página menos uno, estamos obteniendo diferentes data. Y la función de consulta sigue siendo flights fetcher. Y en función de la existencia de data, aquí ves isPreviousData, estamos mostrando u ocultando los botones. Bueno, en realidad no ocultando, sino desactivándolos. Así que cuando cambiamos eso en FTSx de nuevo, por última vez, paginación de React Query, y en realidad tengo que arreglar el punto final de nuevo. Bueno, en realidad, vamos a usar solo el dominio. Apaguemos el throttling. Así que aquí ves que estamos obteniendo los vuelos. La página actual es uno, y vemos los botones de página anterior y siguiente, ¿verdad? Cuando vamos a la siguiente página, nos da los siguientes data. Y cuando llegas a cuatro, a la página cuatro, porque solo hay 10 vuelos, cuando llegamos a la página cuatro, no podemos ir al siguiente, porque ahora no hay más data. Así que React Query es realmente bueno en estos casos cuando realmente quieres, o puedes usar todos los booleanos de estado que están allí para casos de uso más avanzados, como mencioné, con los data iniciales preconstruidos, y así sucesivamente. Es realmente bueno para eso, pero es bastante complicado configurarlo correctamente. Elimina los comentarios. ¿Dejé un comentario en algún lugar? Ah, aquí. En realidad, no debería importar. Pero sí, definitivamente, es una buena práctica eliminarlo. Ahora, por supuesto, hay un montón de otras características. No podríamos cubrirlas todas en este tiempo. Podríamos hacer una masterclass solo sobre las características de React Query. Pero eso me lleva de vuelta a la pregunta final, ¿cómo elegir la mejor? Y si buscas esta pregunta en Google, y pones allí el useSWR, pones React Query, pones allí tal vez Fetch API, o algo así, vas a ver tantos hilos con tantas opiniones. Así que no me gustaría ser el que te diga, usa esto o usa aquello. En realidad, en mis propios proyectos, recurro por defecto a useSWR, porque es el más fácil de usar y el más fácil de configurar. Y entre Fetch y Axios, uso Fetch porque es nativo. Pero diría que, puedes usar el que cumpla con las necesidades de tus proyectos. Y creo que hemos repasado los beneficios de cada uno. Creo que ahora tienes una buena idea, de cuál es útil para qué caso de uso. Así que diría, elige el mejor en función de tu proyecto. Y si tienes alguna pregunta, no dudes en enviarlas en el chat. De lo contrario, esta es la última parte de la masterclass. Así que si quieres ponerte en contacto, definitivamente hazlo. Este es un enlace a mi Twitter, pero también tenemos un servidor de Discord. Así que lo compartiremos en la presentación también, que voy a enviar a todos ustedes, o voy a pedir a los organizadores que lo envíen a todos ustedes. Sí, puedo mostrar la diapositiva anterior, esta es la que es. Lo siento, ahí está. De lo contrario, muchas gracias por unirte. Espero que te hayas divertido. Tuvimos algunos problemas al principio, lo siento por eso, pero no sería una buena masterclass sin algún debugging en vivo, ya sabes. Y sí, como mencioné, si hay algo con lo que pueda ayudarte, no dudes en ponerte en contacto. De lo contrario, aquellos de ustedes que estarán en Londres la próxima semana, asegúrense de pasar por nuestro stand. Y de lo contrario, buena suerte con sus proyectos y que tengan un gran resto del día.