React Query y Auth: ¿Quién es responsable de qué?

Hola, gracias por venir a esta charla sobre React, Query y Auth. Así que React, Query y Auth se superponen en cierta medida, y esta charla va a discutir quién es responsable de qué. Así que primero me gustaría presentarme con este increíble avatar steampunk que React Advanced hizo para mí. Es mi nueva cosa favorita. Mi nombre es Bonnie Shulkin, y he estado en la industria del software alrededor de 20 años. He ocupado muchos roles, pero actualmente soy desarrolladora y formadora. Puedes encontrarme en bonnie.dev, que está en la esquina inferior derecha de todas estas diapositivas. En Twitter, estoy en bonnie.dev con el punto escrito, y estoy increíblemente orgullosa de tener el handle @Bonnie en GitHub. Para introducir esta charla, quiero dar algunas notas. La primera es que aquí voy a hablar de conceptos y realmente no voy a introducir code. Si estás interesado en el code, tendré un enlace al ejemplo de code al final. El enfoque aquí es realmente hacer mi propio sistema para manejar a todos los jugadores que están interesados en la información del usuario y apagado. De esta manera podemos entender todas las piezas. Pero al final, hablaré de un par de bibliotecas npm que puedes usar. Y finalmente, si eres alguien a quien le gusta hacer clic en enlaces de charlas o si te gusta seguir las diapositivas puedes obtener estas diapositivas en mi sitio bany.dev slash talks y puedes buscar la charla de React advanced. He hecho algunos juegos de palabras en algunas de las imágenes que puedes buscar si te gusta ese tipo de cosas.

Entonces, aquí hay una tabla para la tabla de contenidos. Primero, voy a presentar React Query para las personas que no conocen esta increíble biblioteca. Luego hablaré sobre la aplicación para esta charla y qué tipo de suposiciones de authentication utiliza.

Hablaré sobre la solución que tengo para fusionar React Query y Auth. Y luego hablaré sobre esas bibliotecas NPM que mencioné.

Entonces, comencemos hablando sobre React Query. React Query es una biblioteca cuyo trabajo es mantener el estado del servidor en el cliente. Así que hace esto creando una caché de datos del servidor en el cliente. Una de las principales herramientas de React Query es el gancho use query. Y este gancho toma una función de consulta que es responsable de obtener los datos del servidor. Para suscribirse a esos datos, el código de React ejecuta el gancho use query. Ahora, parte del trabajo de React Query es asegurarse de que los datos estén sincronizados con el servidor. Así que use query actualiza los datos del servidor. Extrae nuevos datos del servidor dependiendo de algunos disparadores. Algunos de ellos son automáticos, como una reconexión de red o si la página está enfocada. También puedes invalidar manualmente los datos en la caché y la razón por la que menciono esto es porque hablaremos de eso más adelante en esta charla.

Cuando invalidas manualmente los datos en la caché, entonces use query va al servidor y busca datos frescos. Tengo algunas notas al pie de página aquí. Es una simplificación. React Query es una aplicación bastante sofisticada así que no estoy hablando de muchos conceptos como datos obsoletos y expiración de la caché y así sucesivamente. Hay un par de otros conceptos de React Query de los que me gustaría hablar que son relevantes para esta charla. Uno es las mutaciones. Así que use query es si simplemente quieres buscar datos del servidor. Las mutaciones son si quieres actualizar datos en el servidor y así React Query tiene un gancho use mutation además de un gancho use query. También hay un concepto de consultas dependientes. Así que estas son consultas que puedes activar o desactivar en función del valor de una expresión. Así que si la expresión se evalúa como verdadera, entonces la consulta estará activa y hará todas esas búsquedas de datos como lo hace para mantener los datos frescos. Si está apagado si ese valor es falso, entonces los datos están apagados y no se va a comunicar con el servidor. Debería decir que la consulta está apagada, creo que dije que los datos están apagados.

Ahora me gustaría hablar sobre la aplicación para la que escribí esta solución.

Entonces, esta es una aplicación de un spa de día donde puedes reservar masajes, faciales o exfoliaciones, puedes imaginar en qué estaba pensando cuando escribí esto. Así que tiene tratamientos disponibles que necesita obtener del servidor. También tiene personal que necesita obtener del servidor y un calendario de citas. Y hace todo esto a través de React Query. Estos son datos del servidor bastante básicos para React Query. Pero también tiene una función de inicio de sesión, un usuario necesita estar registrado para poder reservar citas. Y por lo tanto tiene un hook useAuth que permite al usuario o que gestiona el inicio de sesión, el registro y el cierre de sesión. El hook useAuth devuelve funciones de inicio de sesión, registro y cierre de sesión que pueden ser utilizadas. Y el servidor utiliza autenticación con tokens web JSON.

Entonces, esas funciones de inicio de sesión y registro en el hook use off en realidad reciben un token y los datos del usuario en la respuesta del servidor. Y la pregunta es, ¿quién posee estos datos? Así que ahora estamos empezando a entrar en la superposición entre off y React Query. ¿Son estos datos del cliente o del servidor? Bueno, creo que podrías argumentar que el usuario que ha iniciado sesión, el usuario particular que ha iniciado sesión en este cliente, esos son datos del cliente. Pero los detalles del usuario, su nombre, su dirección de correo electrónico, su autorización, esos son datos del servidor. Lamento mucho si puedes oír motosierras. Están talando árboles en el vecindario. Así que los datos del usuario tienen en realidad muchas partes que tienen un interés. Use auth está recibiendo esos datos del usuario cuando hace las llamadas al servidor. Y luego los datos del usuario también necesitan ser persistidos en el almacenamiento local porque queremos asegurarnos de que si el usuario refresca la página, por ejemplo, no se cierre automáticamente la sesión. También hay algo interesante sobre use query aquí. La función de consulta va a necesitar usar el ID. Va a necesitar ese ID de usuario para decirle al servidor de quién obtener los datos. Pero necesita los datos para conocer el ID. Por eso tengo este gráfico de pollo y huevo aquí. Necesitas el ID para obtener los datos, pero necesitas los datos para obtener el ID. Esta es una complicación que puede hacer que te preguntes, ¿por qué querríamos incluso involucrar a React Query en absoluto? ¿Por qué no almacenar simplemente los datos del usuario en un contexto y dejar a React Query fuera de la imagen? Tengo un par de razones por las que creo que React Query es una buena idea cuando se trata de datos de usuario. La primera son las mutaciones. El usuario puede actualizar sus datos, pueden actualizar su nombre o su correo electrónico, y queremos asegurarnos de que el cliente está mostrando datos precisos desde el servidor. Imagina esta situación. Imagina que un usuario actualiza sus datos y luego hay un problema, hay un error de red o Dios no lo quiera, hay un error de programación en el servidor y esto impide una actualización. El usuario necesita saber cuál es el estado actual de los datos en el servidor. Con React Query, podemos manejar eso al invalidar ese valor de caché después de la mutación. Luego, React Query irá y obtendrá los datos reales del servidor. Esto actualizará los datos para cualquiera que esté suscrito a esta caché de React Query, incluyendo, digamos, si tienes el nombre de usuario en la barra de navegación. Cualquier componente tendrá los datos más actualizados. La segunda razón por la que creo que es una buena idea involucrar a React Query es para el inicio de la aplicación. La aplicación va a usar el almacenamiento local o algún almacenamiento del navegador para mantener el inicio de sesión a través de las sesiones para que el usuario pueda refrescar la página. ¿Y si el usuario actualizó los datos desde otro navegador? Digamos que ayer, fueron a un navegador diferente en la casa de un amigo y actualizaron los datos. Nuestra aplicación va a parecer torpe si no tenemos esos datos actualizados cuando vuelvan a iniciar sesión desde su nuevo navegador. Debería decir cuando vuelvan a iniciar sesión desde su navegador que estaban usando antes de ir a la casa de su amigo.

Eso es algo que simplemente hará que la aplicación parezca más sofisticada, pero también hay un problema de seguridad aquí. ¿Qué pasa si teníamos algún usuario en el spa que estaba autorizado para actualizar los tratamientos, e hizo algo realmente mal, y fue despedido. Queremos asegurarnos de que si vuelven a la aplicación, actualizamos sus datos de usuario para que ya no estén autorizados para actualizar esos tratamientos. Es realmente difícil deshacerse de un token en el almacenamiento local, pero React Query puede hacer que podamos actualizar los datos, y podemos asegurarnos de que tenemos datos actualizados al inicio.

Ahora, tal vez te has inclinado hacia el lado de que React Query debería manejar todo. Sin embargo, necesitamos cuidar el uso de la autenticación en el almacenamiento local. Necesitamos conectarlos de alguna manera. ¿Queremos que se suscriban y actualicen la caché de React Query individualmente? Luego también tenemos esa situación del pollo y el huevo para el ID de usuario en la función de consulta.

La solución que he encontrado es descentralizar todo con un hook de usuario utilizado. Esta es la fuente de la verdad. Rastrea los datos del usuario con un estado interno del usuario que se expone como un valor de retorno del hook y esos son los datos canónicos del usuario. Usaremos el almacenamiento local para mantener los datos no solo a través de las sesiones, sino también cada vez que se inicializa un usuario utilizado. También mantendremos los datos del usuario actualizados con el servidor utilizando use query para que cualquiera de esos disparadores que mencioné actualice los datos. Podemos cuidar de esa situación del pollo y el huevo desactivando esa consulta si el usuario es falso. Cada vez que se actualizan los datos del usuario, pasarán por este hook de usuario utilizado. Para asegurarnos de que los datos se mantienen en todas partes donde necesitan estar en el estado interno del usuario, en la caché de consultas, y en el almacenamiento local.

Como me gustan las imágenes, aquí está el hook de usuario utilizado. Recibirá datos de React Query, cuando React Query obtenga datos actualizados del servidor, y también establecerá datos en la caché cuando obtenga datos de usuario de otras fuentes. Otra fuente de la que podría obtener datos de usuario es el hook de uso de autenticación, que recibe datos de inicio y cierre de sesión. El almacenamiento local se está configurando cada vez que se actualizan los datos del usuario, y también está proporcionando el valor inicial para el hook de usuario utilizado. Para profundizar un poco más, el hook de usuario utilizado va a devolver ese estado de usuario para las personas que quieran suscribirse a esos datos de usuario, y luego también va a devolver actualizar usuario, una función de actualización de usuario que toma datos de usuario y actualiza los datos para los tres jugadores. También tendrá un usuario claro, que actualiza los datos para los tres jugadores para que no haya usuario. Actualizar usuario. Y todas las actualizaciones, cualquier actualización de datos de usuario pasa por el uso de usuario. Entonces, cuando React Query actualiza los datos, utiliza la función de actualización de usuario del hook de usuario utilizado. Lo mismo con el hook de uso de autenticación.

Muy bien, esa es mi breve introducción a cómo resuelvo este problema. Si te gustaría ver el código, puedes ir a este repositorio de GitHub y puedes ir a aplicaciones completadas, spa de día perezoso, y cliente en lo que respecta al árbol de directorios. Concluiré esta masterclass hablando un poco sobre las bibliotecas npm que existen. La primera es React Query Auth.

Y aquí está el enlace a ello. Este es un envoltorio bastante ligero alrededor de React Query. Entonces, como usuario de React Query Auth, lo inicializas proporcionando funciones de inicio de sesión, cierre de sesión y registro. Y luego utiliza un proveedor de autenticación separado que toma tu configuración y las funciones de React Query y te proporciona un montón de data y funciones. Así que te da los data del usuario y si hubo o no un error. Luego te da funciones para volver a buscar al usuario, para iniciar sesión, cerrar sesión y registrarse, que es lo que he estado llamando registro. Y luego también te da data sobre si los eventos están ocurriendo actualmente o no.

La forma en que utiliza React Query es que trata el inicio de sesión y el registro como funciones de mutación. Utiliza useMutation para eso porque useMutation te permite ejecutar la función más tarde. Y luego tiene un callback en caso de éxito de estas funciones de mutación para actualizar la caché. Esto no aborda la persistencia en el navegador.

Y aquí, si quieres echar un vistazo al code, como dije, es bastante ligero, en realidad no son tantas líneas de code. También hay una biblioteca de Firebase. Y aquí tienes. Esto en realidad utiliza useQuery para todas las llamadas de autenticación y useQuery toma las funciones de Firebase como las funciones de consulta. Almacena todos los data directamente en la Caché de React Query. Y Firebase en sí, a través de esas funciones de Firebase, gestiona la persistencia en el almacenamiento local y el almacenamiento de sesión, y tiene otras opciones también. Y si te gustaría ver el code para esto, tengo un enlace a eso aquí.

A principios de este mes, ambas bibliotecas todavía están encontrando tracción. Así que puedes ver que React Query Auth tiene alrededor de 500 descargas por semana y React Query Firebase tiene unas 30 descargas por semana, debería decir la parte de autenticación de ella. Puedes comparar esto con alrededor de 575,000 descargas por semana para React Query. Bueno, para concluir esta charla, solo quiero reiterar que la razón por la que esto mereció una charla completa es porque hay tres actores principales cuando se trata de data de usuario. Está React Query, que puede mantener el estado de los data en el servidor. Están las Funciones de Autenticación, que pueden encargarse de recuperar los data iniciales. Y luego está la persistencia a través de las sesiones. Así que puede ser almacenamiento local u otras herramientas de persistencia. Cualquier solución completa necesita abordar a estos tres. Así que muchas gracias por venir a mi charla. Gracias a React Advanced por tenerme y por hacer ese increíble avatar Steampunk.