GraphQL. Gestión del estado

Hola, soy Ankita Kulkarni y la charla de hoy trata sobre la Gestión del Estado en GraphQL. Espero que todos estén bien y que estén teniendo un día o noche maravillosos, dondequiera que estén.

Así que, sí, empecemos. Como dije, soy Ankita. He estado trabajando en la industria tecnológica durante más de 10 años. Actualmente trabajo como educadora y creo productos digitales en línea, como libros electrónicos y cursos, entre otras cosas. Tengo un curso de Next.js y un libro electrónico si quieres echarles un vistazo. Y también creo cosas para ayudarte a crecer como desarrollador.

Un pequeño detalle, todos los fragmentos de código y diapositivas que utilizo en esta presentación específica están disponibles en este enlace y aquí tienes un código de barras muy útil.

Así que empecemos y hablemos sobre la Gestión del Estado en GraphQL. Primero retrocedamos un poco y comprendamos realmente a qué estándares nos estamos adhiriendo, ¿verdad? ¿Qué es un Gestor de Estado? Un Gestor de Estado es básicamente una forma en la que podemos administrar el estado general de nuestra aplicación. Así que cada vez que hacemos una solicitud al servidor, el servidor nos devuelve datos y esos datos pueden o no venir en la forma correcta que deseamos, por eso es importante que usemos un Gestor de Estado para transformar esos datos y acceder a ellos de la forma que deseamos. Así que podemos enviar acciones específicas y luego el estado puede cambiar en general, ¿verdad? Y eso es lo que veremos ahora que entendemos un poco más sobre el Gestor de Estado.

Entonces, ¿qué es un buen Gestor de Estado? Un buen Gestor de Estado nos permite actualizar el estado fácilmente. Podemos acceder al estado fácilmente, ¿verdad? Y hay varias características de un buen Gestor de Estado que podemos analizar ahora. Por ejemplo, tus datos están normalizados. Y lo que quiero decir con eso es que cada vez que actualices datos, cada vez que intentes actualizar una cosa, solo se actualizará esa cosa. Tus datos no se duplican en todas partes, por lo que no tendrás un montón de consultas de tarjetas diferentes, por ejemplo, o datos de tarjetas o datos de productos o cualquier otro dato que estés utilizando en diferentes lugares. Solo tienes esa única pieza de información de estado y un buen Gestor de Estado realmente te permite hacer eso. Ahora los datos se transforman fácilmente. Así que cada vez que, como dije, si los datos que recibes del servidor, si podemos transformar esos datos de manera consistente, entonces, por ejemplo, si quieres mostrar el nombre de un usuario, ¿verdad? Así de simple, un nombre completo, podemos mostrarlo en la página de inicio, en la página de inicio de sesión y donde sea que queramos, pero podemos transformarlo de la manera que deseemos, ¿verdad? También queremos que nuestros datos se transformen de manera consistente. Puedes visualizar tu estado global. Como todos sabemos, la depuración es extremadamente importante. Para ayudar con la depuración, también necesitamos poder visualizar el estado global. Si no tenemos herramientas para hacer eso, no podremos visualizarlo. No sabremos cómo se ven nuestros datos. Estaremos disparando a ciegas, lo cual no es lo que queremos. Y como mencioné, la depuración es mucho más fácil. Puedes depurar tus aplicaciones fácilmente agregando cualquier tipo de registro en la consola o intentando ver cuál es el estado antes y después. Si algo saliera mal, sabrías exactamente qué hacer y qué código específico probablemente lo causó.

Así que conoces muy bien el flujo de los datos. Y como todos sabemos, Redux, que es una biblioteca muy popular de gestión del estado, realmente solucionó la mayoría de nuestros problemas, ¿verdad? El Redux llegó y pudimos gestionar el estado debug fácilmente con las herramientas de desarrollo de Redux, lo cual nos ayudó mucho con el problema específico que teníamos en el front-end. De hecho, también diría que Redux hizo que el desarrollo front-end fuera mucho más fácil porque de repente la manipulación de datos era mucho más sencilla y directa. Debo mencionar que Redux puede no ser tan fácil de empezar si queremos utilizarlo, no es tan sencillo como podríamos pensar, pero una vez que le coges el truco, podrás transformar los datos y manipular tus datos en general, correctamente.

Veamos cómo se ve una solicitud en Redux. En este caso, tenemos un ejemplo muy simple, ¿verdad? Tenemos un carrito, enviamos una solicitud de carrito, un éxito de carrito y un error de carrito. Así que aquí tenemos tres estados diferentes. Cada vez que hacemos cualquier tipo de solicitud en general en nuestro front-end, necesitamos despachar tres tipos diferentes de acciones, y así es como funciona Redux básicamente.

Tenemos que definir una solicitud de carrito, y luego tenemos un éxito de carrito, una vez que obtenemos data del servidor, y también hay un error de carrito. Así que cada vez que solicitamos data para el carrito, puede resolverse en uno de estos estados, puede resolverse en un éxito de carrito o puede resolverse en un error de carrito. Y básicamente mezclamos estos y tenemos estas tres fases de una solicitud de API, ¿verdad? Y una solicitud asíncrona en Redux probablemente se verá así. Ahora este ejemplo específico utiliza Redux Saga, si no lo has usado antes, es básicamente una biblioteca que te permite gestionar tus efectos secundarios asíncronos.

Un efecto secundario es cualquier cosa que, ya sabes, cuando tu aplicación cambia, es capaz de manejar todas las solicitudes asíncronas correctamente. Por ejemplo, en este caso, estamos obteniendo datos del carrito. Y como puedes ver, puedes pensar en yield como un simple fetch, ¿verdad? Y tu yield es como un iterador, que se detiene cuando la solicitud de fetch, que es call, se resuelve, y getCartQuery es básicamente una consulta en el backend, ¿verdad? Ahora, en este caso, lo que estamos observando aquí es, uno, lo que sucede es que escuchamos para, revisamos watch fetch cart data query, y tomamos cada vez, eso significa que cada vez que se hace una solicitud de carrito, invocamos la función fetch cart data. Entonces puedes ver que el número uno, escucha la solicitud de carrito, y el número dos ejecuta la función fetch cart data. Así que esta es una solicitud en Redux con Redux Saga. Es una biblioteca asíncrona que nos permite gestionar nuestras solicitudes asíncronas. Y cuando podemos resolverlo, si tenemos data, básicamente ponemos, nos permite despachar una acción, ¿verdad? Entonces podemos decir éxito de carrito, o en caso de un error, error de carrito. Así que esto fue bastante sencillo. Sabíamos exactamente cómo transformar data. Sabíamos exactamente qué hacer en nuestra aplicación front-end. ¿Qué cambió? ¿Por qué cambiar? Bueno, Apollo, GraphQL sucedió, ¿verdad? GraphQL nos llevó a un viaje, donde no tenemos que solicitar todos los posibles datos del servidor y manipularlos. Solo obtenemos lo que queremos, ¿verdad? Podemos pedir un objeto específico y obtener ese objeto de vuelta. Así que veamos qué sucedió después de que aparecieron los hooks de Apollo GraphQL.

Esto es solo un ejemplo de los hooks de Apollo GraphQL en tu front-end. Entonces, Apollo Client, que es básicamente una biblioteca de cliente para hacer solicitudes GraphQL, nos proporciona diferentes tipos de hooks como useQuery, useMutation, donde podemos hacer solicitudes. Ya sea que podamos obtener data usando useQuery o también useMutation si queremos manipular data o actualizar data, lo que sea. Entonces, por ejemplo, en este caso, tenemos useQuery. Y useQuery llama nuevamente a getCartQuery y en función de eso obtenemos diferentes tipos de resultados. Como loading, error, data y refetch states.

¿Y no es eso lo que queremos? Esto es exactamente nuestra aplicación de frontend. Así que ya no necesitamos acciones. Ya no necesitamos loginRequests, loginSuccess y loginFailure porque podemos simplemente hacer eso con hooks. Y podemos decir simplemente dame tres tipos diferentes de data. Data, éxito y error, ¿verdad? Que es exactamente lo que vimos y también nos da loading para mostrar al usuario alguna interfaz de usuario mientras nuestra aplicación se carga.

Pero todavía hay algunos desafíos, ¿verdad? Como es genial que podamos hacer esto, pero ¿cómo transformamos data? ¿Cómo gestionamos el estado? Digamos que obtenemos un objeto de usuario del backend con un nombre, ¿cómo podemos mostrar nombres de dos formas diferentes en la página de inicio versus la página de inicio de sesión, o de cualquier otra forma que queramos manipular data en general? Entonces, ¿cómo transformamos data, normalizamos data y creamos un millón de acciones y reductores? Lo siento, estoy criticando a Redux, pero ¿cómo hacemos todo eso en GraphQL, ¿verdad? Y como sabemos, con Redux, este era un punto de dolor común, ¿verdad? Así que cada vez que tienes que hacer algo incluso pequeño, ya sabes, realmente pequeño, podrías tener que crear un reductor de acción, y sí, como todos sabemos, ese mismo código se repite una y otra vez.

Entonces, GraphQL, Apollo Client 3 apareció y dijo, acepto el desafío. Y tenemos Apollo Client 3 que resolvió en gran medida muchos de nuestros problemas, y vamos a echar un vistazo a eso, cómo GraphQL nos permite, con Apollo Client 3, ser un muy buen gestor de estado. Y aquí está Apollo Client 3. Es mágico. Echemos un vistazo. Apollo Client 3 se encarga de la mayor parte del trabajo por ti. Así que si, por ejemplo, en Redux, teníamos que hacer todo, ¿verdad? Teníamos que solicitar data, teníamos que resolver data, teníamos que despachar una acción para el error, teníamos que gestionar solicitudes asíncronas y demás, ¿verdad? Apollo se encarga de la mayor parte del trabajo por ti, por lo que no tienes que hacer mucho en el front end. Entonces, ¿cuál es la diferencia entre Redux y Apollo Client? Redux dice, sí, está bien, puedo hacerlo, lo tengo. Y Apollo Client dice, No, no tienes que hacerlo. Yo me encargaré de la mayoría de las cosas por ti. Así que puedes hacer exactamente lo que... Puedes centrarte en el front-end de tu aplicación y hacer exactamente lo que deseas. Entonces, nuevamente, revisemos algunos de los principios de gestión de estado que vimos inicialmente. Dijimos que nuestros data se normalizan, ¿verdad? No queremos duplicados, por ejemplo. Y con Apollo Client 3, definitivamente nos permite hacer eso, porque nuestros data se normalizan de forma predeterminada. No... Nuestros data se normalizan y puedes ver aquí en la consulta raíz. Este es un ejemplo de cómo Apollo Client 3 llevaría un... Realizar un seguimiento de tus solicitudes. Este es un ejemplo de un carrito, y un carrito específicamente, digamos, tiene diferentes productos en él, ¿verdad? Y creará una matriz. Y cada matriz es una referencia a un objeto específico que hemos invocado. Nuevamente, no necesitamos entrar en los detalles exactos de cómo funciona Apollo Client 3 pero necesitas tener una buena comprensión de cuáles son los mecanismos internos, para que puedas manipular data fácilmente. Y con Redux, también hay un concepto de inmutabilidad que surgió, que es que cada vez que actualizas el estado, siempre se forma un nuevo estado, ¿verdad? Concretamente con Apollo Client, tener esa comprensión de cómo funciona realmente nos dará una buena idea.

Entonces, las transformaciones de datos eran la segunda característica que tiene un buen gestor de estado. Veamos cómo podemos hacer transformaciones de datos en Apollo Client. Este es otro ejemplo, ¿verdad? En el lado derecho, verás un archivo de muestra data.json, donde podemos ver los productos nuevamente. Tenemos Glossier, y como nombre del artículo es lápiz labial, precio, y así sucesivamente. Es un producto de comercio electrónico muy típico, ¿verdad? En el lado izquierdo, tenemos getCartQuery, y en la parte inferior, podemos invocar esa consulta, ¿verdad? Nuevamente, así es como invocaríamos los datos. Declararíamos exactamente lo que queremos e invocaríamos esa consulta dentro de nuestro componente de React usando useQuery.

Entonces, ¿cómo manipulamos los datos entonces, verdad? ¿Cómo hacemos más cosas con ellos, por ejemplo? En este caso, nuevamente, si te fijas, estamos manipulando los datos. Así es cómo podemos manipular los datos. En el lado derecho, nuevamente, es el mismo producto, ¿verdad? Pero en el lado izquierdo, estamos invocando la consulta, y ya vimos la consulta en la diapositiva anterior, pero estamos invocando la consulta y aquí simplemente mostramos si mostrar getOutOfStockText o low stock text. Si el stock menos la cantidad es menor o igual a 2, entonces es bajo en stock. De lo contrario, si dice que está fuera de stock, está fuera de stock, ¿verdad? Nuevamente, un ejemplo muy simple, pero así es como puedes manipular los datos porque exactamente obtienes los datos de GraphQL. Pero podrías imaginar que los datos se repetirán, ¿verdad? Digamos que quieres mostrar ese mismo producto en diferentes lugares, quieres asegurarte de que también estemos almacenando el mensaje de fuera de stock en todos los lugares diferentes.

Echemos un vistazo a lo que los campos solo locales están introduciendo campos solo locales. En este caso, podemos ver que tenemos Apollo Client y Apollo Server, y en la caché misma, podemos agregar más datos. Cada vez que se realiza una consulta GraphQL o una consulta de Apollo client y obtenemos datos en el frontend, podemos agregar datos adicionales a esa caché. Todos los datos se almacenan en Apollo Client 3 en forma de caché, ¿verdad? Al igual que Redux, todos los datos se almacenaban dentro de un gestor de estado. Por ejemplo, si actualizáramos la página, los datos desaparecerían, tendríamos que volver a cargar todo de nuevo. Lo mismo ocurre aquí, es una caché, y debemos asegurarnos de que también estemos almacenando nuevos datos en esa caché. Entonces, ¿cómo puede Apollo Client diferenciar entre los datos del servidor y los datos del frontend, verdad? Esto es exactamente lo que vamos a ver. Puedes ver aquí que el texto de stock tiene este valor específico junto a él llamado atClient, y eso nos permite especificar que resolvamos este campo específico en el lado del cliente, ¿verdad? Y luego, cuando queremos resolverlo, cuando hay un atClient junto a él, simplemente podemos llamar a la caché para obtenerlo.

Echemos un vistazo a un ejemplo, el mismo ejemplo, nuevamente, la misma consulta de carrito, ¿verdad? Lo que sucede es que en la parte inferior, estamos invocando la consulta dentro del componente de React. Y todos conocemos eso, ya hemos revisado ese código. Pero en la parte superior, para el texto de stock, Apollo Client resolverá el texto de stock en el lado del cliente, ¿verdad? Nuevamente, getCartQuery es exactamente el mismo, pero además del texto de stock que podemos resolver en el lado del cliente, lo cual es increíble. Los campos solo locales nos permiten hacer eso. Podemos declarar tantos campos solo locales como queramos. Ahora, si podemos imaginar, si ese mismo objeto de carrito se muestra de diferentes maneras, también podemos acceder al texto de stock en todos los lugares diferentes de nuestro frontend. ¿No es increíble? Entonces, nuevamente, si quieres agregar, definir más campos del lado del cliente en el propio tipo de GraphQL, que no necesitan provenir del servidor, podemos definir campos solo locales para que puedas resolver el estado localmente, ¿verdad? En tu frontend.

Ahora este es un ejemplo, nuevamente, un ejemplo básico de lo que es la caché en memoria y cómo la estamos declarando. Nuevamente, esa caché de la que hablé en el frontend, se llama caché en memoria. Y podemos declarar un campo llamado texto de stock, si ahora queremos resolver ese texto de stock, ¿verdad? El texto de stock, podemos declararlo con el derivado at client, pero luego en el código mismo de la caché en memoria, debemos decir a qué se resolverá ese texto de stock.

Y esta es la función para eso. Nuevamente, si recuerdas, vimos este código exactamente hace unos cuantos diapositivas, donde lo estábamos haciendo en el frontend. Pero ahora, en cambio, podemos hacerlo directamente en el producto. Hay políticas de tipo dentro de la caché en memoria. Y en el tipo de producto, estamos agregando un nuevo campo llamado texto de stock. Y eso nos permite manipular data, ¿verdad? Entonces, ahora el texto de stock puede ser 'agotado' o 'bajo en stock' dependiendo del producto.

Luego vienen las variables reactivas. Nuevamente, estas son mis variables favoritas. Y sé que estamos viendo mucho código en esta presentación específica, pero todos los fragmentos están disponibles en el enlace. Mencioné inicialmente, también compartiré ese enlace más adelante en esta presentación de diapositivas. Muy bien. En este caso, nuevamente, las variables reactivas nos permiten, nuevamente, reaccionar a una acción específica. Entonces, de manera similar a cómo teníamos en Redux, teníamos una solicitud, un éxito y un error, ¿verdad? Teníamos una acción. De manera similar, las variables reactivas reaccionan a valores específicos. En este caso, nuevamente, estamos diciendo si el usuario ha iniciado sesión, obtenemos el token de la cookie, ¿verdad? Luego declaramos una variable reactiva, y cómo declaramos una variable reactiva es usando la función makeVar de Apollo Client. Y luego, en eso, podemos almacenar cualquier función que queramos. Y luego, en la parte inferior, nuevamente, en las políticas de tipo, podemos extenderlo y agregar isUserLoggedIn y declarar esa variable reactiva isLoggedInUserVar. Entonces, nuevamente, esta es otra forma de reaccionar. Y la mejor parte es que en el frontend, entonces, podemos decir, cada vez que el usuario haya iniciado sesión, ¿verdad?, podemos usar otro hook llamado useReactiveHook dentro de nuestra aplicación y luego decir, ya sea que se resuelva a la aplicación o al inicio de sesión. Y cómo podemos actualizarlo es, nuevamente, podemos acceder directamente a la variable y actualizar el componente. Y estas variables reactivas, sinceramente, son mis favoritas. Y realmente nos ayudan a unir todas las cosas de las que hablamos de un buen gestor de estado. Podemos decir que data está transformada. Usamos campos solo locales, usamos variables reactivas, ¿verdad? Y creo que otra cosa importante aquí es que debemos mantener una mente abierta, ¿verdad? Entiendo que amamos Redux y la inmutabilidad es algo con lo que vivimos porque React funciona de esa manera, ¿verdad? Siempre necesitamos actualizar el estado todo el tiempo. Pero realmente necesitamos hacerlo, si Apollo Client está haciendo la mayor parte del trabajo pesado por ti, entonces podemos simplemente usar eso y luego acceder, agregar variables reactivas cuando necesitemos esa reactividad en el frontend, y agregar campos solo locales cuando necesitemos agregar esos valores adicionales del cliente que la capa de transformación son esos campos solo locales con políticas de tipo, ¿verdad?

Eso es todo para esta presentación específica. Antes de que te vayas, quiero decirte nuevamente que todos los fragmentos y diapositivas están disponibles en este enlace específico, y también puedes usar el código de barras. Ahora, mantén una mente abierta como resumen de esta presentación específica, y si quieres revisar alguna de las diapositivas y fragmentos que compartí aquí, sería muy divertido revisar este enlace específico. Y por último, para ayudarte a crecer como desarrollador, he estado creando estos fragmentos visuales semanales como parte de mi boletín informativo, BlueDuty 2 GraphQL, React, Next.js. Entonces, nuevamente, si quieres las últimas noticias del front-end o algo para reflexionar o un bocadillo para reflexionar, puedes consultar el boletín informativo de bocadillos del front-end que compartí. Muchos de los fragmentos que compartí se mencionan en ese boletín. Puedes suscribirte aquí, y nuevamente, aquí está el código de barras también. Así que esto es prácticamente el final. Si tienes alguna pregunta, comentario, comentario o si quieres contactarme después en Twitter o en cualquier otro lugar donde tengas preguntas. Y muchas gracias por ver este video y escuchar esta charla. Realmente espero que tengas un día o noche maravillosos. Muy bien, gracias. Muchas gracias.