Gestión del estado en React con Context y Hooks

Cuando comenzamos, o al menos cuando yo comencé a trabajar con React, creo que todos decían que Redux era la herramienta dorada para la gestión del estado y a menudo encontrarías, al menos si estabas buscando trabajo, que Redux era una habilidad deseada para prácticamente todas las empresas que trabajaban con React. Y también la gente pregunta sobre React, así que cada vez que hacía masterclasses, la gente me hacía preguntas sobre cómo usar Redux, cómo implementarlo, por qué deberías usarlo para la gestión del estado o por qué no. Y creo que la discusión sigue siendo muy relevante hoy en día. E incluso con nuevas herramientas como la API de contexto, se ha vuelto cada vez más relevante. ¿Es Redux realmente la mejor herramienta para tu producto? ¿Deberías estar usándolo? Así que hoy no te diré cómo usar Redux, pero te mostraré algunas alternativas y también cómo se comparan esas alternativas con Redux. Un poco sobre mí, mi nombre es Roy, puedes encontrarme en Twitter con el nombre gethackteam, y actualmente soy el encargado de los equipos de ingeniería en Vandebron, que es una empresa de energía renovable en los Países Bajos. También trabajo junto con el equipo de Sailor, y Sailor es una API de comercio electrónico para en realidad más que un simple producto, algo similar a lo que Strapi o GraphCMS hacen para los sistemas de gestión de contenido, pero para el comercio electrónico. También es una herramienta muy útil que utiliza mucho React en el front-end. Y es posible que ya me conozcas por algunos de los libros que he escrito sobre React o React Native o por las charlas que he dado sobre esos temas, pero también mucho sobre GraphQL, así que si estás interesado en eso, por favor encuéntrame en línea. Y también hace poco tiempo, creé este nuevo libro sobre cómo crear aplicaciones full stack con GraphQL, y tanto en el back-end con GraphQL y TypeScript como en el front-end con React y XGS, así que si estás interesado en ese tipo de cosas, sí, puedes encontrarlo aquí en este sitio web.

Así que hoy, volvamos al estado. Antes de entrar en detalles, veamos qué es realmente el estado, porque el estado puede ser muchas cosas y a menudo también puede estar viviendo dentro de un menú. Hace dos años, estaba creando una biblioteca de código abierto para la ciudad de Ámsterdam, donde también vivo, y allí estábamos trabajando con el estado, por supuesto.

También creamos una biblioteca de componentes, por lo que también trabajamos con menús y elementos de menú dentro de ese menú. Y el menú se veía así. Tenías un menú simple que podía estar abierto o cerrado, y si estaba abierto, el estado pasaba y decidíamos mostrar un submenú. En esta solución, casi siempre pasamos el estado hacia abajo. Simplemente puedes crear un menú y pasar el estado hacia abajo, ya sea que el menú esté abierto o no, y luego, en función de eso, harás algo dentro de tal vez un componente hijo, tal vez renderices un componente hijo.

Y en esta solución, casi siempre usas estado local, ya sea un estado en un componente de React basado en clases o tal vez si estás usando componentes de función, entonces usarías el hook useState. Y creo que para cosas simples como esta, como tener un menú, tener un submenú o tal vez solo un elemento de menú, siempre eliges usar estado local porque no tiene mucho sentido implementar algo más grande como Redux o la API de contexto o tal vez una de esas otras herramientas que existen. Pero si tienes un menú más complejo, ya necesitas considerar si aún quieres usar un estado local simple en React. Porque tal vez tengas un menú, tengas un submenú, haya un elemento de menú o tal vez el elemento de menú dentro del submenú sea otro submenú, en teoría, podríamos ir indefinidamente lejos.

Y en esta solución, ya es bueno comenzar a pensar en el estado, como qué tan complejo debe ser mi estado o qué tan simple debe ser. Este podría ser un ejemplo de tu menú. Tal vez tengas un menú hamburguesa para dispositivos móviles. Podría estar abierto o cerrado. Entonces aún tienes un estado simple como abierto es verdadero o falso. Pero tal vez también tengas un hijo adentro que podría estar abierto o cerrado, por lo que también tienes un estado para el hijo abierto o cerrado allí. Esto ya está empezando a verse un poco más complejo, y especialmente si quieres que las personas se mantengan en el mismo estado cada vez que actualicen la página. Creo que se está volviendo cada vez más complejo y son cosas en las que debes pensar.

También puedes estar usando, si has trabajado en una biblioteca de componentes antes, probablemente te hayas preguntado acerca de los componentes accesibles. Si quieres que tu componente sea accesible, quieres que ciertas partes se resalten cuando alguien use el teclado para navegar en lugar de su mouse. Si estuvieras en esa situación, tal vez también quieras saber qué hijo está seleccionado, por lo que no solo quieres saber si el menú está abierto, si un submenú está abierto o en realidad qué submenú está abierto, sino que también quieres saber qué hijo está seleccionado. Y esto se vuelve bastante complejo y también depende de hasta dónde quieres llegar, porque no creo que necesites definir IDs en el estado para determinar qué submenú está abierto, pero tal vez si quieres hacer esto, ya se vuelve más complejo.

Y esto todavía es algo para lo que puedes usar bastante fácilmente el estado local. Pero ya hay algo en lo que debes pensar si aún pasaras la prop zona. Y creo que para estos escenarios en los que tendrías un menú con un elemento de menú o tal vez un menú con un submenú o múltiples submenús y elementos de menú dentro de él, creo que es probablemente sencillo decir que simplemente puedes pasar el estado hacia abajo, crear estado local en los componentes padres y pasarlo como props. Y en el componente padre, administrarás el estado local, te asegurarás de que los elementos del menú estén abiertos o cerrados, independientemente de las acciones que alguien esté tomando en tu aplicación. Pero ¿qué pasa si estos componentes no son menús o submenús o elementos de menú? Entonces, si estos componentes son toda tu aplicación o incluso rutas dentro de tu aplicación o componentes dentro de rutas dentro de toda tu aplicación, si estuvieras en esa situación, probablemente ya no usarías el estado local porque quieres que tu estado sea más diverso.

Y cuando hablamos de más diverso, siempre pienso en el tablero de ajedrez. El ajedrez se ha vuelto cada vez más popular, creo, especialmente con todos los programas de Netflix y todos los documentales geniales al respecto. Entonces, cuando piensas en el estado, también puedes pensar en un tablero de ajedrez. ¿Quieres que tu estado sea simple? ¿Quieres que tu estado pueda pasar de un campo a otro o de un componente a otro? El peón es en realidad la pieza más básica en el ajedrez, o ¿quieres que tu estado sea más complejo? ¿Quieres que pueda omitir componentes o campos para poder retroceder y avanzar? ¿Es eso algo que quieres que haga tu estado? Y si ese es un escenario, entonces no te ayudará lo suficiente usar solo el estado local con tal vez el hook useState o incluso el hook useReducer. Ese es un escenario en el que probablemente quieras hacer más y realmente necesitas más.

Y con ese escenario, tal vez podrías haber terminado usando la API de contexto o usando useReducer, pero antes de que esas funciones estuvieran disponibles, probablemente terminaste usando algo como Redux o MobX, o si estás usando GraphQL, algo como Apollo. Y todas estas bibliotecas se crearon porque React carecía de ciertas características y no podía hacer la gestión del estado de manera efectiva. Especialmente para hacer la gestión del estado de manera efectiva. Entonces, creo que la API de contexto nos ayudó mucho al agregar estas características adicionales y te mostraré cómo puedes usarla.

Entonces, la agenda para hoy, principalmente te daré una introducción durante unos 30 o 40 minutos, y luego trabajaré en ejercicios en salas de trabajo. Y luego, entre medias, podemos sincronizarnos para ver los ejercicios. Dependiendo de qué tan rápido vaya hoy, tal vez no podamos hacer todos los ejercicios de una vez. Afortunadamente, tenemos el canal de Discord, y creo que ya lo compartí en el chat, y Lira también estaba allí. Entonces, si no estás en el canal de Discord, por favor, avísale a través de Discord, y ella puede agregarte al canal y podemos discutir los ejercicios incluso después del masterclass de hoy. El masterclass de hoy se trata principalmente de la API de contexto y cómo puedes usarla para gestionar el estado de manera efectiva en cualquier aplicación de React. Y en realidad, antes de algunas versiones de React atrás, se recomendaba no usar contexto porque si quieres que la aplicación sea estable, no uses contexto, es experimental.

Y creo que fue un mensaje muy bueno porque muchas cosas han cambiado en la API de contexto. Y algunas personas incluso dicen que no deberías usarla para la gestión del estado, pero creo que también es un poco una pregunta más opinativa para muchas personas. Pero antes de esta versión de React, en realidad se recomendaba no usar la API de contexto de React para la gestión del estado. Y en realidad, React también te decía, o al menos la documentación de React te decía, si no estás familiarizado con las bibliotecas de gestión del estado como Redux o MobX, no uses contexto y simplemente usa estas bibliotecas porque están mejor probadas, son construidas por la comunidad y pueden tener muchas características que de otra manera no tendrías. Entonces, ¿cómo funciona la API de contexto? La API de contexto se puede ver como una especie de estado o estado local, o no necesariamente tiene que ser estado local, pero podría ser estado local, que envuelve varios componentes. Desde varios componentes, deberías poder acceder a este valor de contexto y también acceder a funciones para actualizar el valor de contexto.

Y crear un contexto se puede hacer utilizando el método createContext de React. Este método te ayudará a crear un objeto de contexto. Un objeto de contexto contendrá varios componentes, como el proveedor de contexto. Así que siempre comienzas creando el contexto, después de lo cual puedes crear el proveedor de contexto. En este escenario, mi contexto consiste en dos cosas, el proveedor de contexto y también el consumidor de contexto. Y en realidad, necesitas ambos para configurar la API de Contexto.

Entonces, al principio, siempre necesitas crear un proveedor de contexto al que le proporcionarás un valor dinámico. Esto establece el valor del contexto, después de lo cual puedes consumirlo utilizando el componente consumidor. El componente consumidor hace que el valor del contexto sea accesible, tal como lo ves aquí. El valor que se coloca en el proveedor de contexto es el mismo valor que leerías desde el consumidor. Y todo esto se hace utilizando componentes de React, y hay otras formas de leer el valor del contexto, pero eso es lo que te mostraré más adelante.

Pero es posible que ya pienses que esto se ve familiar, ¿verdad? Porque si has estado usando Redux antes, probablemente veas que con React Redux tienes la misma configuración. Creas un proveedor, le agregas un store, y el store es en realidad tu valor de contexto. Si observas la API de contexto, debes envolver toda tu aplicación. Entonces, desde cualquier lugar de tu aplicación, en realidad puedes leer el valor del store desde un consumidor. Por lo tanto, la configuración es bastante similar y el enfoque también es el mismo. Así que si vienes de Redux, no hay muchas diferencias en cuanto a la configuración. Y también si has estado usando React con Apollo o tal vez algún otro proveedor para GraphQL, entonces probablemente veas que con el proveedor de Apollo haces algo similar. Creas un proveedor, no pasas realmente un valor a él, sino que le pasas un cliente. Y con este cliente, puedes conectarte a la API de GraphQL. Y este proveedor también envuelve toda la aplicación y desde cualquier lugar dentro de tu aplicación, puedes acceder a los clientes. Puedes hacer llamadas a la API de GraphQL para obtener ciertos datos. La configuración sigue siendo la misma. Creas un proveedor. Envuelve partes de tu aplicación o tal vez toda tu aplicación. Y luego puedes acceder a estos valores desde cualquier lugar dentro del árbol de componentes que envolviste con el uso de un consumidor. Así que espero que esto se vea bien y también un poco familiar si has trabajado con React durante mucho tiempo.

Entonces, ¿cómo podemos implementar esto? En realidad, hay varias formas de implementarlo, pero esta es una forma muy básica de hacerlo. Ya hemos comenzado. Primero creas un contexto y utilizando este objeto de contexto, obtendrás un proveedor, al que le proporcionarás un valor dinámico. Y dentro del proveedor, colocarás un componente como hijo de este componente de React. Así que el componente que veremos aquí es en realidad un componente hijo, y el componente hijo puede consumir nuestro contexto de React. Esto sigue siendo muy similar a cómo lo hacemos con Redux y React, pero también con otras cosas como Apollo. Tenemos un proveedor, el proveedor tiene un valor, y ese valor puedes consumirlo desde cualquier componente dentro del proveedor. Y también puedes hacer esto con hooks, porque espero que todos hayan estado revisando los componentes de función, y probablemente para muchos de ustedes, los componentes de función son su forma principal de crear componentes de React. Por supuesto, con la API de contexto, también podemos usar hooks. Y se ve prácticamente igual, así que aún tendrías que crear un contexto y luego, utilizando ese contexto, puedes llamar al hook useContext de React. Así como useState o useReducer, este es un hook incorporado. Con este hook incorporado, puedes pasarle tu objeto de contexto y luego puedes obtener el valor del contexto utilizando este hook. Aún tienes un objeto de contexto y aún tienes un proveedor al que le pasas el valor, pero en lugar de tener un componente consumidor, en realidad estás pasando tu objeto de contexto al hook y luego puedes leerlo y usarlo dentro de tu aplicación. Creo que esta es una forma mucho mejor. Es posible que sea un poco menos declarativa, pero aún te brinda una base adecuada para usar el valor del contexto. Y también lo que realmente me gusta es que ya no tienes que usarlo dentro de un renderizado. Cuando tienes el consumidor, también necesitas acceder al valor desde dentro de un renderizado. Y al usar hooks, ya no tienes que hacer esto. Esto es algo que me gusta de los hooks en general y los componentes de función, pero también es una buena adición al uso de la API de contexto, no tener que obtener el valor del proveedor de contexto desde dentro de un renderizado, sino simplemente usando un hook. Así que comparemos los dos enfoques. El primero es donde tienes que consumirlo desde dentro de un renderizado utilizando el componente consumidor. O el otro enfoque es donde tienes que usar el hook de contexto en el que consumirás los objetos de contexto. En ambos escenarios, aún necesitas importar el objeto de contexto.

Aún tienes mi consumidor de contexto que necesitas importar desde mi contexto. Y el otro enfoque, aún tienes que importar el objeto de contexto y usar el hook para leerlo. Entonces, al actualizar el contexto, ya vimos que el valor del contexto es un valor dinámico y es algo que puedes pasar tú mismo. Por lo tanto, también se puede actualizar el contexto proporcionando una función de actualización al contexto. ¿Cómo funciona esto? Esto es lo que vimos antes. Puedes crear un contexto y luego obtendrás un proveedor de contexto que debes configurar y puedes pasarle cualquier valor dinámico. ¿Qué es este valor? Puede ser cualquier cosa. Y preferiblemente será algo relacionado con el estado, porque si estamos usando el estado de React, ya tenemos funciones de actualización, ya tenemos funciones que son dinámicas y ya estamos provocando que React se actualice cuando cambiamos algo. Por lo tanto, actualizar el contexto puede hacerse fácilmente si observas cómo usas el hook useState.

Todavía tendrías que crear el valor del contexto, tendrías que crear un valor de estado local. Utilizaremos el hook useState de React para crear un valor de estado. Y la configuración aquí es bastante arbitraria. Si usas una predicción, se ve un poco diferente porque casi nunca creas un objeto de estado utilizando useState, para eso usas el hook useReducer, pero más sobre eso más adelante. Pero muestra cómo debes abordar esto. Utilizarías el hook useState para crear un valor de estado. Y un valor de estado es algo que pasas a tu proveedor. Y también a tu proveedor le pasarías la función de actualización para tu estado local. Por lo tanto, tu proveedor consistiría en las variables de estado, pero también en las funciones de actualización para tus variables de estado. Y al pasar estas al proveedor, puedes consumirlas dentro de tu aplicación. Entonces, si estamos aquí, puedes ver que tenemos un consumidor de contexto. Estamos consumiendo el valor del contexto y en realidad estamos usando la función de actualización desde dentro de nuestro contexto para actualizar el valor del estado, que luego actualizará nuestro valor del contexto nuevamente. Al hacerlo, en realidad estamos utilizando la gestión interna del estado de React para el estado local. Y en realidad hemos pasado esto a nuestro contexto y podemos usar ambos. Y con esto, obtenemos muchas ventajas porque ya estamos utilizando los sistemas internos de React. No necesitamos crear algo. No necesitamos usar algo de una biblioteca externa. Y todo esto es solo React, lo cual también me gusta. Y al hacerlo, creo que hemos llegado a la parte importante, cuando haces esto con React, debes asegurarte de separar las responsabilidades entre sí, porque si abordas la gestión del estado de esta manera, es muy fácil llegar a situaciones en las que tendrías problemas de rendimiento. Y los problemas de rendimiento probablemente no sean tan grandes porque React en sí mismo sigue siendo eficiente y probablemente tendrás pequeñas demoras, tal vez incluso de milisegundos. Entonces no es algo de lo que realmente debas preocuparte, pero es algo que puedes evitar que suceda separando realmente los proveedores de los consumidores.

Entonces, ¿qué quiero decir con esto? Al separar los proveedores de los consumidores, puedes echar un vistazo a este enfoque, puedes crear componentes que solo tengan un proveedor de contexto y que representen a todos los componentes. Entonces, tu proveedor de contexto puede ser un componente que tenga el proveedor de tu objeto de contexto, pero también tenga todas las variables de estado locales. Y al separar los proveedores de los consumidores, podrás asegurarte de que no se realicen actualizaciones innecesarias, porque probablemente ya sepas que si colocas muchas variables de estado diferentes en un componente de React y luego todo se actualizará cada vez que algo cambie. Eso es algo que quieres evitar. Al separar las responsabilidades, puedes hacer que React sea más eficiente, también puedes facilitarle a React o incluso a Next.js si eso es algo que estás usando, saber cómo se alinean los componentes, cómo funcionan juntos. Y también es algo interesante de ver. Y si observamos las DevTools para React, tienes el perfilador allí y en esto puedes ver qué sucede cuando separas estas responsabilidades. Entonces, cuando uses la API de contexto para algo un poco más complejo que tal vez solo tener el modo oscuro activado o desactivado en tu aplicación, asegúrate de separar esos proveedores. Y puedes hacer esto fácilmente creando un nuevo componente proveedor, que es solo un componente de React que tiene el proveedor de tu objeto de contexto. Y aquí puedes ver que cuando haces esto, simplemente pasas todo lo que colocaste dentro de él como hijos. Entonces, todo el árbol de componentes, que no es solo un componente, simplemente lo pasas allí y tienes la propiedad children en React, que simplemente puedes usar dentro de tu proveedor y luego devolver todos esos hijos. Esto tampoco es algo complicado, es algo que, sí, algo que sabes si estás usando React, el componente children, algo que simplemente le pasas. Y luego puedes pasar fácilmente todo el árbol de componentes. Y también, si estamos actualizando el contexto y hemos separado esas responsabilidades, también necesitas exportar tu objeto de contexto porque tu objeto de contexto viviría en tu componente proveedor. Y luego, por supuesto, necesitas exportarlo. Por lo general, uso el contexto para, podemos usar este objeto de contexto para obtener todos los valores de nuestro contexto, que ahora son solo count y updateContext. Y en esto, simplemente puedes actualizarlo desde cualquier componente dentro del árbol de componentes. Entonces podemos ver aquí que el componente ahora es solo un componente con algunos elementos HTML, pero podría ser un árbol de componentes completo. Desde cualquier lugar dentro de este árbol de componentes, podríamos usar este hook useContext para obtener valores de tu contexto. Y luego simplemente podrías actualizarlos desde tal vez un evento onClick o un botón, o tal vez programáticamente cuando obtengas información de una API o de alguna otra fuente de datos.

Y para esto, también puedes crear tus propios hooks para manejar esto. Y para demostrar esto, déjame abrir un código sandbox para ti. Código sandbox. Aquí tengo algunos ejemplos de React. Sí. Entonces aquí puedes ver, he creado un simple contexto y déjame ir a mi archivo de índice. Y aquí, ahora también lo compartiré en el chat, o tal vez sea más fácil en el canal de Discord. El enlace del código sandbox, ahí vamos. Sí, aquí he creado un pequeño ejemplo de cómo usar la API de contexto con estado local. Y aquí podemos simplemente actualizarlo para ver las advertencias en la consola. Puedes ver que tenemos, bueno, solo un contador simple con un botón y es el mismo código que acabamos de ver en mi pantalla. Así que déjame ir aquí. Sí, lo que estamos viendo aquí es solo React. He importado React. En versiones posteriores no es necesario hacerlo, pero no rompe tu código. También estoy importando nuevos estados y creando contexto. Entonces lo que estoy haciendo aquí es crear un valor de contexto, un objeto de contexto utilizando createContext, y luego tengo mis componentes, que es donde pongo mi proveedor y allí pongo el estado local, count y setCount. Y luego paso el segundo componente a esto, que es este. Y ese es el que realmente consume esto. Y también lo pongo en esto, tal vez un poco más limpio. Esto y luego el segundo componente, que está envuelto dentro de mi proveedor. Puedo obtener valores del contexto porque lo que estoy haciendo aquí es usar el hook useContext y también podría reestructurarlo si quiero, count, setCount. Lo que sea que esté haciendo aquí es cada vez que hago el evento onClick, usaré un valor de useContext, que es setCount para reemplazar la variable de estado para counts. Entonces esto es solo React y simplemente combina useState, useContext y setContext para crear una herramienta de gestión de estado local pequeña y eficiente. Ok, algunos problemas aquí. Probablemente esté relacionado con algo más. Pero sí, como puedes ver, es bastante sencillo. También compartí el enlace en el canal de Discord. Así que asegúrate de echar un vistazo y probarlo tú mismo. Pero a lo que iba es que, si estás haciendo esto y estás separando las responsabilidades, también estás creando tus propios componentes proveedores. También puedes crear tus propios hooks para manejar esto. Y crear un hook en React suena un poco más complejo de lo que realmente es. Porque crear un hook no es realmente crear un hook, simplemente estás siguiendo el estándar de crear un hook, que también implica tener una función. Idealmente una función pura y agregarle 'use'. Entonces, cualquier cosa que pongas allí, use algo detrás, estás creando un hook en React. Así de simple. Así de simple. A la izquierda puedes ver un ejemplo de dicho hook y aquí puedes ver que también estoy extendiendo o, sí, creo que extender es la mejor palabra, el hook useContext de React. Entonces, cuando creas tu propio hook en React, generalmente también estás extendiendo hooks existentes. Y aquí puedes ver que nuestro hook useContext está devolviendo valores de nuestro contexto. Y esto es algo que harás en este escenario, pero tal vez no tenga mucho sentido porque no estamos cambiando ninguno de los valores en nuestro contexto. Pero por lo general, también podría cambiar valores de su contexto, tal vez combinar varios contextos juntos y realmente tiene sentido crear su propio hook y poder usar esto. Y otra ventaja interesante es que no necesitas importar el objeto de contexto en cada componente que esté usando contexto, sino que solo tienes que importarlo dentro del hook que creaste tú mismo. Entonces, ese hook está usando useContext para mutar o obtener el valor del contexto. A la derecha puedes ver cómo puedes usar dicho hook de contexto para usar valores del contexto. Y es casi lo mismo que verías con cualquier otro hook, simplemente estás usando tu propio hook personalizado para obtener valores de un hook de React diferente que podrías haber alterado o simplificado o tal vez hayas extendido de alguna manera. Y esto es algo que también puedes ver en los ejemplos en el código sandbox, puedes ver aquí cómo puedes crear tu propio hook y cómo puedes extenderlo. Entonces, tal vez aquí podrías haber hecho la obtención de datos, otros efectos secundarios que podrías estar haciendo allí. Estas son todas las cosas que podrías hacer allí.

Creo que siempre es mejor mantener estas cosas puras porque quieres saber qué entra y qué sale. Pero tal vez algo más que podrías hacer aquí es combinar múltiples contextos. Este podría ser mi segundo contexto en caso de que tuvieras alguno. También es una buena manera de combinar cosas de múltiples formas.

Y algo más que es bueno, de lo que te hablaré un poco más, es también usar el contexto junto con el hook use-memo. El hook use-memo es un hook que puedes usar para memoizar valores. Puede que hayas oído hablar de cómo memoizar componentes de React, pero puedes hacer lo mismo para la API de Contexto y también para los valores que pasas a la API de Contexto. ¿Cómo se ve esto? Por lo general, cuando tienes un contexto, es lo mismo que con el estado local. Si tienes un estado local en tu componente padre y lo pasas a los componentes hijos, cada vez que cambies algo en tu estado local, todos los componentes hijos se volverán a renderizar. Y lo mismo ocurre con el contexto. Si tienes un valor de contexto, envuelves componentes con él. Estos componentes están usando algo de tu contexto. Si el contexto cambia, entonces, por supuesto, estos componentes intentarán volver a renderizarse. Y con el contexto, podría ser el caso de que también suceda que los componentes se vuelvan a renderizar cuando en realidad no necesitan hacerlo, porque tal vez el valor de contexto que están usando no se está actualizando realmente. Por eso es importante también ver si necesitas usar el hook useMemo, porque no quieres que las actualizaciones en una parte de tu árbol de componentes actualicen componentes, o en realidad no se actualicen, sino que se vuelvan a renderizar en otro lugar de su árbol de componentes cuando en realidad no cambió nada para ese componente. Ahí es donde entra en juego el hook useMemo.

El hook useMemo es algo que puedes agregar a tu proveedor. Aquí tenemos un proveedor simple. Está tomando counts y una función de actualización para counts de un hook de estado local, el hook useState. Y antes de pasar este valor a nuestro proveedor, en realidad estamos usando el hook useMemo para memoizar este valor. Y si ya has visto el hook useEffect, probablemente estés familiarizado con el array de dependencias. También el hook useMemo tiene un array de dependencias. Usando el array de dependencias, solo actualizará el valor a través del hook useMemo cuando el valor de count cambie. Entonces, si alguien está usando la función updateCount, creo que las funciones son una mejor manera de verificar también en los arrays de dependencias porque a menudo no se comparan de una manera excelente. Siempre es mejor tomar valores como count, que es solo una cadena o un entero, porque esas cosas se comparan fácilmente. Pero si miras esto, puedes ver que el valor del proveedor de contexto solo cambiará cuando count cambie. Entonces, si nada cambia en count, entonces no debería haber motivo para que el proveedor o el contexto en este caso se actualicen. Y esto también se asegurará de que ningún componente que esté usando este valor se actualice a menos que el valor de count cambie. No si alguien hace algo con la función updateCount o se pausa, se llama o se anula, esta es una función en uno porque es por eso que solías usar memo. También, déjame mostrarte un ejemplo de esto. Vamos a volver aquí. Vamos a volver al código sandbox. Y aquí puedo mostrarte un ejemplo de cómo se ve con el memo. La consola para esto. Primero, la aplicación, borra la consola. Oh. Sí. Entonces, cada vez que mi aplicación se renderiza por primera vez, y es algo que puedes ver. En realidad, se renderizan dos componentes, ¿verdad? Entonces, se renderiza todo el componente de la aplicación, que básicamente es todo lo que verás en esta página, y también el componente. Y el componente es básicamente esto. Así que primero hagámoslo sin el valor memoizado. Cada vez que se renderiza mi componente, puedes ver que la aplicación se renderiza y el componente se renderiza. Y la aplicación es toda la aplicación, que es todo lo que verás. Y el componente es solo la parte con el contador y el botón. Entonces, cada vez que renderizo la aplicación, por supuesto, la aplicación y el componente se vuelven a renderizar. Pero cuando actualizo el contexto, solo cambia el contexto, lo cual está bien. Cada vez que renderizo la aplicación, mi componente también se renderiza. Bueno, en realidad nada cambió para mi componente porque count sigue siendo el mismo, pero aún así, estoy renderizando mi aplicación y este componente se renderiza. Al memoizarlo, puedes evitar que esto suceda.

Entonces, solo estoy actualizando el contexto. Por lo tanto, también puedes volver a renderizar mi aplicación sin que mi componente se vuelva a renderizar porque el contexto envuelve todo y el renderizado de mi aplicación no debería volver a renderizar este componente porque nada cambió aquí. El contador sigue siendo siete. No cambié el valor de mi contexto porque cuando renderizo el componente de la aplicación, pero cuando no lo cambio, en realidad solo la aplicación debería renderizarse. Esto no ocurre la primera vez porque la primera vez no tenemos un contador, se actualiza fácilmente, luego ambos. Pero si no memoizas este valor, como esto, entonces en realidad verás que cada vez que renderizo mi aplicación, también se renderizarán mis componentes, lo cual podría ser extraño y es algo que intentas evitar, y por lo general React es muy bueno evitando esto por ti. Pero siempre hay casos excepcionales y casos en los que no lo hace. Y en realidad puedes evitar que esto suceda mucho simplemente separando la lógica del proveedor de los consumidores. Eso es algo importante que hacer. Y también manteniendo los proveedores pequeños. Entonces, si mantienes los proveedores pequeños, hay menos posibilidades de que actualices cosas innecesariamente.

Entonces, ¿qué sucede si tengo una lógica más compleja? Ya hemos tocado este punto brevemente. En React, cada vez que creas un estado, tienes el hook useState, que es para un estado local muy simple, pero también tienes el hook useReducer. Y el hook useReducer es un poco más complejo porque detecta dos variables, que son el estado inicial del reductor y devuelve una matriz que consta del estado y una función de despacho. Entonces, lo que devuelve para el estado es en realidad el estado actual. Y cada vez que montas tu aplicación, la ejecutas por primera vez, el estado actual probablemente será igual al estado inicial que proporcionas al hook useReducer. Pero también devuelve una función de despacho. Y la función de despacho se puede usar para actualizar estados. Y cómo actualizar los estados dependerá de la función reductora. Entonces, tu función reductora es una función que toma el estado actual, a veces también toma el estado inicial, pero toma el estado actual y basado en el estado actual y lo que sea que despaches. Entonces, cualquier entrada que le des a la función de despacho, devolverá el nuevo estado. Estos son conceptos importantes para recordar. Entonces tenemos que usar el hook useReducer. Toma dos cosas, el reductor para devolver un nuevo estado y también el estado inicial. Y devuelve el estado actual a menudo igual al estado inicial y también una función para actualizar el estado que llama al reductor, que luego creará un nuevo estado.

Entonces, ¿cómo se ve esto? Tu función reductora probablemente se verá algo así. Es una función que toma los estados actuales y la acción, y la acción es algo que uso este nombre porque estoy familiarizado con Redux. Entonces toma dos cosas, el estado actual y también la acción o lo que sea que pongas en tu función de despacho. Y basado en lo que pongas en tu acción, que es lo que pongas en tu función de despacho, hará algo con el estado. Por ejemplo, si en tu función de despacho proporcionas este objeto, que tiene un tipo y un payload, que es muy similar a Redux. Y por eso elegí esta configuración porque he estado trabajando con Redux durante mucho tiempo. Entonces, basado en lo que ponga en mi función de despacho, que es un tipo de incremento, hará algo con mi estado actual basado en lo que también haya puesto en mis funciones de despacho. Entonces, un payload. Y basado en esto, devuelve un nuevo estado. Entonces, el nuevo estado será el recuento, el nuevo recuento, que es el recuento actual. Y también, suma el recuento que tenemos de nuestra función de despacho. Y también, sí, toma el estado actual y hará algo con tu estado actual. Y nuevamente, ya mencioné Redux varias veces. Todo puede verse muy familiar porque Redux, típicamente, un reductor en Redux se verá algo así. Tendrías un estado inicial, tendrías una acción. Basado en el tipo de acción, harías algo y mutarías el estado. Entonces, tomé muchos conceptos que tienes en Redux para que sea más familiar, pero también porque Redux en general está configurado de manera bastante eficiente. Estos son conceptos que aún puedes usar con la API de Contexto, pero ya no tienes que usar Redux. O puedes usarlo junto con Contexto. Y si quieres usarlo junto con Contexto, por supuesto, necesitas crear un estado inicial y un reductor, pasarlos a un hook useReducer, devuelve el estado actual y la función de despacho. Y esas son cosas que pasarías a tu Contexto. Entonces, en tu Contexto, tendrías un valor, que es básicamente el estado que proviene de un hook useReducer. Y también funcionalidades que se llaman la función de despacho. Entonces, nuevamente, esto se parece mucho a lo que hicimos con el hook useState local, pero ahora es un poco más complejo y también un poco más eficiente porque realmente estamos usando el proveedor de Contexto ahora para exponer nuestro estado del hook useReducer a todo nuestro árbol de componentes. Y si quieres actualizar el valor desde el Contexto, simplemente puedes llamar a la función decreaseContext o increaseContext, que a su vez son llamadas funciones de despacho del hook useReducer. Y esto es algo que puedo mostrarte nuevamente si volvemos al código sandbox. Iríamos aquí, tendríamos desde Contexto con Reductor. Eso probablemente sea. Entonces, aquí puedes ver que tenemos una configuración un poco más compleja para que podamos increaseContext, podemos decreaseContext. Y cada vez que presiono uno de estos valores, en realidad enviará una función de despacho para mi hook useReducer, que es algo que puedes ver aquí. Entonces, tengo un ContextProvider, tengo un estado inicial, tengo una función reductora, y ambos los pasaré al hook useReducer. Que a su vez hará algo con estos valores. Bien. Y en mi ContextProvider, lo he configurado como valor para mi estado reductor, ese es el valor para mi contexto. Y también he puesto las funciones de despacho, que están envueltas en una función diferente. Entonces, esto también es por qué es bueno separar la lógica del proveedor de contexto del consumidor real porque aquí puedes enviar cosas. Tal vez puedas tener efectos secundarios, tal vez puedas enviar y luego, según lo que regrese, puedes tomar diferentes acciones. Estas son cosas que puedes hacer en tu ContextProvider. Y nuevamente, aquí puedes ver desde tu componente, que está consumiendo el contexto, puedes usar un UseContextHook o puedes crear tu propio hook, que vimos antes, que también harás en los ejercicios más adelante. Entonces, este componente aquí es capaz de hacer clic en funciones que provienen del contexto. Y en base a eso, hará algo con el valor del contexto. Entonces, lo aumentará o lo disminuirá. Tan fácil como eso.

Entonces, ¿qué hay de la depuración? Una de las cosas buenas de Redux es que viene con muchas funciones para la depuración. Desafortunadamente, la API de contexto no tiene depuración incorporada, pero por supuesto, puedes usar un simple registro de consola o tablas de consola y envolver tus funciones de despacho con otras funciones. Así que podrías crear fácilmente tu propio hook, sin realmente tener useReducer, pero creando y extendiendo con tu propio hook, teniendo useReducer con registros, y luego simplemente extendiendo tu función de despacho con algo que lo registre. Y luego, como consumidor de esta API o de esta aplicación, simplemente puedes llamar al useReducer con registros desde un hook en lugar del hook useReducer, y ya tendrás una función de despacho que permite el registro. Esto es algo que puedes ver en este ejemplo. Asegúrate de ir al CodeSandbox y ver cómo se verá para poder usarlo realmente. Y este es un componente que se renderiza. En realidad, puedes ver que cada vez que hacemos algo, se registrará lo que sucedió. Esto es una console.table. No mucha gente lo sabe, pero en realidad puedes registrar cosas en forma de tabla en lugar de solo registros. En realidad, es una característica bastante buena de JavaScript.

Entonces, ¿qué pasa si quieres un contexto global? Porque eso es probablemente lo que necesitarías si realmente quieres tener gestión del estado para tu aplicación. También querrías un contexto global. Y puedes hacer esto, nuevamente, separando la preocupación de tus proveedores en diferentes componentes proveedores. Y aquí puedes ver, podemos recrear diferentes proveedores por categoría. Así que esto podría ser una aplicación de comercio electrónico. Tal vez tendrías un proveedor para el contexto de productos, uno para el contexto de categorías, uno para tu carrito o para cualquier otro progreso de pago. Y luego tendrías un contexto global que envuelve todos estos diferentes proveedores de contexto. Y tu contexto global, puedes exportarlo, puedes pasarle componentes hijos. Y luego, tal vez cuando configures tu aplicación y estés usando algo como React router, puedes hacer que el contexto global envuelva toda tu aplicación. Así que esta podría ser la configuración que realmente estés usando aquí. Puedes tener el contexto global envolviendo toda tu navegación. Y luego, desde cualquier componente, como productos o detalles de productos, puedes obtener información tanto del contexto de productos como del contexto de categorías. Y luego, desde cualquier componente, básicamente puedes obtener la información de algo. Ok. De manera similar a lo que estamos haciendo aquí. Pero más sobre esto porque esto es algo que también verás en los ejercicios.

Entonces, para resumir, puedes utilizar el contexto para pasar datos al árbol de componentes. También puedes utilizar hooks para esto. De esta manera, puedes acceder fácilmente a este contexto desde cualquier lugar en un árbol de componentes. Puedes utilizar un bucle useContext para obtener valores del contexto. También puedes utilizar los hooks useState o useReducer para asignar valor al contexto. Además, es importante entender que el contexto no es una solución para todos los problemas de estado. El contexto puede ser una solución para tu estado, pero también se puede utilizar de diferentes maneras. Verás a personas utilizándolo como una especie de caché local. Verás a otras personas utilizándolo para trabajo en equipo, tal vez para bibliotecas de componentes. Pero también verás a personas utilizándolo para estados e incluso estado global, aunque no sea realmente global porque global implicaría que se puede utilizar en cualquier lugar, pero más bien como estado de la aplicación. Así que diría que el estado global es algo que compartes con una API, y el estado de la aplicación es algo exclusivo de la API. El contexto definitivamente podría ser una solución para eso.

Y si quieres aprender más sobre esto, utilizaremos el resto del taller para crear ejercicios en los que te colocaré en salas de trabajo. Asegúrate de encontrar el enlace de CodeSandbox aquí y también en el canal de Discord para poder jugar con el contexto en un entorno aislado, un lugar aislado. Y luego, en los ejercicios, te mostraré cómo hacer esto con más detalle. Los ejercicios los encontrarás en mi repositorio de GitHub, donde puedes encontrar todos los repositorios en los que trabajo. Y no es el repositorio del gancho de contexto de React, es el taller del gancho de contexto de React. Así que también compartiré el enlace contigo en el canal de Discord. También lo compartiré aquí en el chat. Déjame ver. Ok.

Entonces, lo que haremos ahora es que primero te mostraré más sobre el repositorio de GitHub. Luego, puedo tomarme unos cinco minutos para responder preguntas del chat. Y luego te colocaré a todos en salas de trabajo. Veamos cuántas personas tenemos ahora mismo. Zoom. Es agradable cómo puedes perder fácilmente las cosas si tienes demasiado en tus pantallas. Así que Zoom está en algún lugar aquí. Lo veré aquí. Tenemos 58 participantes, los colocaremos, creo, en 10 salas de trabajo diferentes en las que estarás con cuatro o cinco personas. Tal vez seis para trabajar en los ejercicios. Y luego, revisaré regularmente con todos para ver cómo lo están haciendo. Pero por ahora, te mostraré cómo configurar esto. Así que irás al enlace de los ejercicios que también mostré en el chat. Y aquí, puedes ir a cualquier lugar fácilmente. Por lo general, guardo mis códigos en este directorio porque solía usar Atom como mi navegador, no el ID del navegador. Entonces, simplemente harías git clone y colocarías la URL del repositorio y se configurará. Luego, solo puedes hacer yarn y yarn start y se instalará todo para hacer los ejercicios. Todos los ejercicios se enumeran aquí y hay un total de 11, pero también algunos bonos. Así que no espero que puedas hacer todo hoy a menos que seas muy rápido y tal vez seamos muy rápidos y eso sería genial. Pero si no, todavía tenemos el canal de Discord para discutir más adelante. Dicho esto, asegúrate de ir a este repositorio y clonarlo. Así tendrás una versión local de todos los ejercicios y aquí encontrarás todo el código. También se utilizará una API que se alimenta de esto. Así que utiliza una API local. No es tan complejo, pero asegúrate de que funcione. Y si no logras que funcione, por favor, no utilices el chat ahora para hacer preguntas, sino espera hasta que estés en una sala de trabajo para hacer las preguntas a un grupo más pequeño.

Déjame ir al chat y ver si puedo responder algunas preguntas. Sí, estoy a punto de iniciar un editor con Atem en estos pero no lo he estado usando durante mucho tiempo. Así que creo que fue mi primer ID real cuando finalmente me deshice de Notepad+++. Buenos tiempos en el pasado. Déjame ver si puedo encontrar algunas preguntas para responder. Veo que la gente está preguntando sobre otras cosas para la gestión del estado, compartir el code sandbox, lo cual es bueno. Entonces, ¿cómo evitamos tener muchos proveedores diferentes? Sí, creo que estas son preguntas como ¿pasarías los despachadores y luego exportar los creadores de acciones? Es algo bueno si tienes una aplicación más grande. Si tienes una más pequeña, tal vez no deberías hacer eso. Pero no importaría tanto. Creo que también determina un poco cómo quieres estructurar las cosas y cómo trabajas en equipo. Y también cuál es tu punto de partida. Creo que estaría bien comenzar pasando la función del despachador. Pero sí, idealmente, sería bueno realmente crear creadores de acciones. Así que, sí, también tenemos preguntas en Discord. Intentaré responderlas también allí. Por ahora, te colocaré en salas de trabajo, pero también has estado escuchándome durante aproximadamente una hora. Así que asegúrate también de tomar un breve descanso. Así que déjame crear una sala de trabajo. Primero, compartiré mi pantalla.

Hola, ¿cómo les fue a todos en los ejercicios? Pensé que sería bueno dedicar los últimos 15 o 20 minutos que tenemos juntos a algunas preguntas y respuestas. Así que si tienen alguna pregunta o tal vez algunos ejercicios en los que la gente ya se haya quedado atascada, podemos dedicar este tiempo a echarles un vistazo. Siéntanse libres de desactivar el silencio o usar el chat si tienen alguna pregunta o ejercicios específicos que deseen discutir.

Así que mi pregunta es un poco sobre refactorización. En el contexto de las reseñas, puedes obtener todas las reseñas y luego, para cada hotel, puedes seleccionar la lista de reseñas asociadas a ese hotel, o puedes obtener las reseñas directamente para ese hotel. Hay pros y contras entre ambas opciones. Y sé que no es el alcance de esta sesión, pero ¿crees que hay un problema de rendimiento o una solución que podría ser mejor que la otra?

Sí, hay varias formas de manejar esto. Debes asegurarte de nunca obtener datos que no vayas a utilizar. Creo que eso es lo principal. Entonces, lo que puedes hacer y lo que también mostramos en, no sé qué pregunta fue, que hiciste en la pregunta ocho. O tal vez ya lo hayas hecho antes. Y al menos en la pregunta, no sé si todos lo sabían, pero también hay diferentes ramas para cada solución. Eso es algo que podrías, si te quedaste atascado, puedes echarle un vistazo. Pero si me quedo tal vez en el ejercicio cinco aquí. No, tal vez alguien más sabe. Pero hay tantos ejercicios de solución donde la lógica de obtención de datos está dentro del contexto, pero la función para comenzar a obtener los datos está en el componente que está utilizando los datos. Eso asegurará que no obtengas datos que no estás utilizando, porque es algo que quieres evitar. En general, nunca debes comenzar a obtener datos desde un componente diferente si no se activa con una función y el componente que está utilizando los datos. Porque de lo contrario, se vuelve muy confuso. No sé si eso responde a tu pregunta. Sí, sí. Gracias. Pero es algo, sí, el rendimiento es algo en lo que hay que pensar al usar el contexto, porque, sí, si no divides las cosas correctamente, terminarás en una situación donde tendrás problemas de rendimiento porque obtienes muchos datos, juntas muchas cosas. Y también React volverá a renderizar si cambias algo en el contexto a menos que establezcas límites adecuados. Así que es algo en lo que hay que pensar, sin duda.

¿Puedes mostrar tu pantalla y revisar tu solución para ver cómo lo hiciste? ¿A qué te refieres? Si puedes revisar la solución y explicar, ya sabes, lo hicimos, pero explicar claramente por qué lo hiciste. ¿Para qué pregunta? Puedo hacerlo, pero necesitas decirme qué preguntas. Oh, lo siento. Pregunta tres y cuatro, tal vez. De acuerdo. Pregunta tres o cuatro. Sí, definitivamente. Sí, así que la pregunta tres era obtener las reseñas del hotel desde la API REST. Sí, así que déjame ver, dónde está la terminal. Francés. De acuerdo, así que para la pregunta tres, contribuimos para este hotel, así que puedes anotar que esta pantalla fue en detalle. Hay algo de estilo aquí, que puedes ignorar. Así que esta fue todavía en dos partes. Quiero que usemos el efecto para obtener los datos para el hotel. Así que adivina para el hotel, que también solo necesitaría obtener si el ID del padre coincide. Así es si tienes HTTP localhost 3000, barra hotel, barra uno. Aquí uno es el ID del padre que coincide. Y básicamente es el primer factor de usuario. Y luego es el segundo factor de usuario basado en el ID del hotel para obtener las reseñas y también tiene su propio estado local. Por lo general, quieres tener diferentes factores de usuario para diferentes efectos. Porque cada efecto secundario debe tener su propio factor de usuario, porque así puedes separar fácilmente las preocupaciones. En este escenario, lo que podrías haber hecho es, de hecho, tener el mismo porque ambos están utilizando el ID del padre que coincide, pero en caso de que tal vez el ID del padre no esté definido o algo así, entonces no quieres tenerlos en lo mismo. Y tal vez también este es un ID que no existe.

Entonces, la gente podría poner cosas locas aquí. Como tal vez esto. Probablemente no sea un ID que se pueda encontrar en la API REST. Por eso es mejor separar las responsabilidades. Y luego ambos tienen su propia función de obtención de datos. Ambos establecen las reseñas para la reseña y este establecerá el hotel. Esta lógica es algo que también podrías haber puesto en un aspecto diferente, o al menos la obtención de datos porque es casi lo mismo, pero los resultados son diferentes. Pero eso es sobre la pregunta tres.

Pregunta cuatro, déjame revisar. Sí, en la pregunta cuatro se pone interesante porque aquí estamos creando un contexto. Entonces, lo que deberías haber hecho para esto, hotelsContext, así que probablemente esté en hotels. Sí, crearías un contexto aquí utilizando el método createContext. Luego creamos un proveedor de contexto, que utiliza el hotelsContext que creamos aquí para establecer un proveedor. Y si hay un proveedor específico, provienen del estado local. Básicamente, lo que hice, todas estas cosas estaban aquí anteriormente, todas estas cosas, básicamente todo esto. Así que antes estaba aquí, estaba en el componente de hoteles. Así que establecí mi estado local, hice mi obtención de datos y en función de eso, usaré estos valores aquí. Pero ahora, en cambio, lo que voy a hacer es crear un contexto para ello, así que puedes eliminar todo esto. Creas un archivo de contexto, estableces el estado local aquí. Es como copiar y pegar, haces la obtención de datos y los resultados de esto no los muestras, sino que los pones en un contexto. Así que también se convierten en valores de contexto y nuestro contexto es algo que exportamos. Entonces, en hoteles, podemos importar el contexto de hoteles. Y delante del contexto, podemos obtener los errores de carga en hoteles, que antes obteníamos del estado local, pero ahora los obtenemos del contexto y el contexto los obtiene del estado local. Básicamente, copiamos mucha lógica de un componente de hoteles al contexto, lo que hace que este componente sea más simple y también más fácil de refactorizar y reemplazar, y el contexto tiene toda la lógica allí.

Pero lo que mencioné antes es que lo que realmente no quieres hacer es esto. Entonces, el useEffect es algo que no quieres hacer aquí. Más adelante, en uno de los ejercicios más avanzados, se mostrará que para obtener los datos, lo que realmente quieres hacer es también pasar esta función aquí. Entonces, quieres tener la función de obtención de datos en tu contexto y luego desde aquí, simplemente haces esto, obtienes los datos y luego tendrías un gancho useEffect. La matriz de dependencias podría estar vacía. Podría ser que hotels.length sea cero al principio, o en realidad no exista, así que gracias, editor. Y luego obtienes los datos. En realidad, lo que quieres hacer es esto. Entonces... Entonces, lo que hace, el contexto tiene una lógica para obtener los datos, pero tu componente decide cuándo se obtendrán los datos. Entonces, en tu gancho useEffect, decidirás que quieres obtener los datos. Cada vez que obtengas los datos, llamamos a esta función desde el contexto. Oh, no esa. Contexto. En el contexto, se llamará a esta función y cuando se llame, establecerá los hoteles, establecerá la carga en falso y establecerá el error en verdadero en caso de un error. Y luego se actualizará el contexto. Los hoteles cambiarán. Primero será, entonces... O renderización inicial en realidad. Así es este. Y luego después de establecer la obtención de datos, los hoteles serán... Alguna matriz con datos. Algo así. ¿Eso respondió a tu pregunta? Sí, gracias.

De acuerdo, bien. Sí, ¿tienes una pregunta, Paolo? Sí, disculpa. Creo que es una pregunta general pero no entiendo cuál es la mejor manera de gestionar los errores con un contexto. Para mí es algo difícil entender cuál es la mejor manera de hacer esto. Sí, realmente depende del tipo de error y de cómo quieras delimitar tu error. Si es un error al obtener datos, puedes agregar el error al valor del contexto. ¿Tienes otros tipos de... No sé, ¿de qué errores estamos hablando? Sí, por ejemplo, de esta manera cuando podemos agregar hoteles a la lista y, por ejemplo, si falla la obtención de datos con la lista de hoteles, algo así. De acuerdo, sí, simplemente los agregaría a un contexto y luego, si más adelante tienes un useReducer, será más fácil ver qué está sucediendo y cuál es el error real. Oh no, estoy hablando de, por ejemplo, el estado de error y establecer el error en el catch pero creo que en algunos proyectos podría ser difícil entender cuál es la mejor manera de mantener los errores o, por ejemplo, si tenemos diferentes listas de data y tenemos diferentes tipos de errores. Sí, entonces cada contexto se especificaría para ciertas cosas, tendrías un contexto para las reseñas, un contexto para los hoteles y cada contexto puede tener sus propios errores. Y creo que ahí deberías decidir si quieres tener errores para todo lo que salga mal, si quieres tener un error global, eso también es algo que puedes hacer. Pero creo que es más una pregunta general de gestión de estado. Entonces, ¿qué tipo de errores quieres agregar ahí? Creo que también depende del lado, como lo que quieres mostrar a tus usuarios. Entonces, si quieres mostrar a tus usuarios que hay un error y ya está. Y puedes tener un error global por contexto. Si quieres mostrar a tus usuarios qué está sucediendo, entonces podrías tener un error por parte del contexto. Entonces, si quieres mostrar a tus usuarios, no sé, tal vez un correo electrónico debería estar, un campo de entrada debería estar lleno y también deberían completar algo más y deberían completar todas las cosas. Ahora también podrías especificar tu contexto, como tener un campo de entrada para el correo electrónico, un campo de entrada para el nombre, un campo de entrada para el cuerpo y luego tener un error por campo o simplemente tener el error global. Entonces realmente depende de lo que quieras mostrar. Entonces, el contexto, lo que agregas ahí realmente debería ser lo que también uses para mostrar a los usuarios. Entonces, si no quieres mostrar errores detallados, entonces no deberías tener que hacerlo, si quieres hacerlo, ahora puedes usar el contexto para eso. ¿Tiene sentido? Sí, tiene sentido. Sí, esa es la pregunta. Si es mejor, por ejemplo, tener diferentes contextos para hacer esto, por ejemplo, un contexto global y actualizar este contexto global si es necesario. De acuerdo. Genial. Casi hemos terminado en términos de tiempo. ¿Alguna última pregunta de alguien? Tal vez una rápida de mi parte. Si digamos que tenemos use states, productores, proveedores y contexto y todo, y tenemos exactamente la misma implementación, pero todo con use states, ¿hay algún beneficio de rendimiento entre ellos con use states regulares y use reducers? Sí, puedes usarlos uno al lado del otro. Pero si tienes cosas más complejas, entonces será mejor usar use reducers. Así que creo que también es bueno lo que dicen en la documentación de React sobre esto, intenta y encuéntralo. Entonces, use state es muy bueno, pero si tienes cosas más avanzadas, entonces sí, use state ya no es tan... Ya no es tan bueno porque lo que sucede con use state es que sobrescribe todo el objeto de estado cada vez que haces una actualización. Y eso es algo que quieres evitar que suceda. Así que sí, en realidad he visto a personas que tenían use state que tal vez eran como 10 en un componente y luego lo reemplazaron con use reducer y su componente se volvió mucho más rápido. Esa es solo mi experiencia. Diría que si tienes tres o algo así está bien pero si tienes tal vez más entonces será hora de refactorizarlos. De acuerdo, genial. Bueno, espero que todos hayan disfrutado. Todavía tenemos el canal de Disco en caso de que tengan alguna pregunta o tal vez si comenzaron a trabajar en los ejercicios más tarde lo pondré en el chat nuevamente para asegurarme. También publicaré allí un pequeño resumen de lo que discutimos, como todos los enlaces para que puedan verlos más tarde. Y también pueden encontrarme en Twitter en caso de que tengan alguna otra pregunta y sí, solo espero que hayan disfrutado y les deseo una buena tarde o mañana o tarde, dependiendo de dónde se encuentren. Así que sí, gracias a todos. Gracias. Gracias. Gracias. Me voy a despedir. Gracias, adiós. Adiós. Adiós, gracias. Ciao. Adiós. Adiós.