Café con Tech

State Management and React Query with Tanner Linsley

August 11, 2021 Matias Hernández / Tanner Linsley Season 3 Episode 5
Café con Tech
State Management and React Query with Tanner Linsley
Chapters
Café con Tech
State Management and React Query with Tanner Linsley
Aug 11, 2021 Season 3 Episode 5
Matias Hernández / Tanner Linsley

A new open sorcerer came to the show. The creator of the Tannstack Tanner Linsley talks with us about State Management and React Query.

During the episode you'll listen about how React Query came to be, the pains that Tanner felt working with other state management solutions, and one hot take about state management that is really important for the React Query philosophy and something that not only Tanner thinks: Not all state is global, Server State is different than Client State.

Links:

Music Credits

Opening and Outro Music by DanoSongs https://danosongs.com/

Background Music Music:

Funky Boxstep by Kevin MacLeod Link: https://incompetech.filmmusic.io/song/7919-funky-boxstep License: https://filmmusic.io/standard-license


Auth0
Auth0 es una plataforma de autenticación y autorización lista para usar en tu app!

Cloundinary MDE
Energizing a diverse community of developers to share knowledge using media technology in web apps.

Escuela Frontend
Conviértete en un Frontend Dev Profesional Contenido de alta calidad para mejorar tu carrera!

Support the show (https://www.buymeacoffee.com/matiasfha)

Show Notes Transcript

A new open sorcerer came to the show. The creator of the Tannstack Tanner Linsley talks with us about State Management and React Query.

During the episode you'll listen about how React Query came to be, the pains that Tanner felt working with other state management solutions, and one hot take about state management that is really important for the React Query philosophy and something that not only Tanner thinks: Not all state is global, Server State is different than Client State.

Links:

Music Credits

Opening and Outro Music by DanoSongs https://danosongs.com/

Background Music Music:

Funky Boxstep by Kevin MacLeod Link: https://incompetech.filmmusic.io/song/7919-funky-boxstep License: https://filmmusic.io/standard-license


Auth0
Auth0 es una plataforma de autenticación y autorización lista para usar en tu app!

Cloundinary MDE
Energizing a diverse community of developers to share knowledge using media technology in web apps.

Escuela Frontend
Conviértete en un Frontend Dev Profesional Contenido de alta calidad para mejorar tu carrera!

Support the show (https://www.buymeacoffee.com/matiasfha)

Español

[00:00:00] Matías: Bienvenidos a un nuevo episodio de cafe con tech en este especial 

temporada en inglés 

hoy conmigo está el propio brujo abierto. Co-fundador de Nozzle creador de react-query Tanner Linsley Bienvenido Tanner. 

Gracias a 

por estar aquí. 

[00:00:15] Tanner: Sí, ya lo creo.

[00:00:15] Matias: En caso de que la gente aún no te conozca. Y puedes ayudarnos con nosotros, tal vez una pequeña introducción para ti. 

[00:00:23] Tanner: Claro. He sido profesionalmente la programación de alrededor de. Ocho nueve años ahora. Y como dijiste, tengo una startup llamada nozzle. Usted puede encontrar un conjunto nozzle.io. Y durante los últimos siete años hemos estado trabajando en la ingeniería inversa, los rankings de búsqueda de Google. Así que salimos y rastreamos todos los rankings de búsqueda que importan a su empresa.

Y volvemos y te presentamos ese día. Ya sabes, con un sistema de análisis de grandes datos y te mostramos dónde te posicionas y dónde se posicionan tus competidores y por qué la gente se posiciona donde lo hace. Así que, sí, es, ha sido muy divertido. Ha sido un desafío técnico y junto con esos desafíos. Ha traído la oportunidad única de construir software de código abierto para mi propia startup que luego puedo utilizar para resolver esos problemas.

Y de ahí han surgido muchos de mis proyectos de código abierto.

[00:01:25] Matías: En realidad su trabajo de código abierto se convierte en

 como tannstack porque 

en realidad tienes un montón de cosas para, para compartir con el mundo de react. Y una de ellas, en particular, es la consulta de react, ¿verdad? Así que es una especie de, su mayor. Éxito en la fuente de números, o al menos el paquete que es 

siendo la mayoría la que lo utiliza. 

Y creo que la gente sabe al menos la audiencia que trabaja con react. No no sobre la equidad real, pero puede tipo de describir un poco, ¿cuál es la magia detrás de react-query ¿Cuál es la razón tal vez que se convierte en tan exitoso entre los usuarios de react? 

[00:02:06] Tanner: Sí. Creo que desde muy temprano en el trabajo con los datos de obtención de Reactor. De cualquier fuente asíncrona era un poco de un desafío. Recuerdo, ya sabes, desde el principio de aprender react, aprendí Redux y Redux es genial y es un gran gestor de estado global. Pero al final, el día que necesitaba para obtener una gran cantidad de datos desde el backend.

Usted puede imaginar. La construcción de un producto que, ya sabes, tenemos una API que estamos mostrando un montón de datos a nuestros usuarios y trabajar con un montón de APIs crudeza. Eso era algo que tenía que hacer mucho. Y recuerdo como no era, era probablemente sólo como un, ya sabes, un par de horas en el aprendizaje. Que dije, bueno, ¿cómo puedo obtener datos?

Y la respuesta fue, bueno, necesitas usar estas cosas llamadas thunks. Yo estaba como, de acuerdo, ¿puedo usar sólo promesas? Y es como, sí, puedes. Pero tienen que estar dentro de este thunk. Y tienes que darle a esas cosas un lugar para vivir dentro de tu tienda Redux. Y todo es global. Y es como, vale, genial.

Como si yo sólo fuera a través de los movimientos. Así es como aprendí. Al igual que muchas otras personas. Pero a medida que pasaba el tiempo, ya sabes, sus limitaciones crecen en lugar de aplicaciones más grandes. Y eventualmente necesitaba, ya sabes, más de un sistema robusto que iba a mantener mis datos En mi aplicación hasta la fecha tan a menudo como sea posible y hacer mutaciones y la lectura que los datos realmente flexible.

Y esta sintaxis para leer datos asíncronos en Redux. Bueno, no es mi favorita. Así que me quedé con Redux durante mucho tiempo hasta que salieron los hooks. Y cuando salieron los hooks, vi una oportunidad única para usar la nueva sintaxis de los hooks para hacer más fácil el trabajo con datos asíncronos. Así que internamente.

en Nozzle. Empecé a construir una solución que se conocería como react query. Y la usé internamente en nozzle durante un par de meses hasta que estuvo lista para el código abierto. Así que después de haber construido react query internamente en nozzle, lo liberé a finales de 2019. Y sí, es decir, necesito. Y es por eso que lo construí porque quería algo que simplemente iba a hacer mi vida más fácil y me permitió trabajar más rápido.

Al parecer, muchas otras personas también necesitaban una consulta sobre la reacción, porque después de que la publicara, recibió mucha atención de otros desarrolladores que querían contribuir a ella. La gente que quería construir herramientas en la parte superior de la misma. Incluso otros frameworks que querían utilizarlo internamente. Así que ha recibido mucha atención, buena atención y ayuda de algunos desarrolladores increíbles.

Y ya sabes, al final escribí un curso sobre ello. Así que tengo un curso de vídeo llamado react, query essentials, y, ya sabes, hay toneladas de ejemplos y un montón de documentación, y se ha convertido en un muy maduro. Biblioteca en el ecosistema de react. Así que.

[00:05:13] Matias: Creo que vi.

una aplicación 

o al menos tomaron prestado el nombre y algunas de las implementaciones, de react-query en Svelte. 

Como 

svelte query usando los paquetes de react query core. Así que es un poco sorprendente que es una especie de difusión a través de todo el ecosistema de JavaScript. Una cosa que resuena mucho con mí con, eh, reaccionar consulta es una de las cosas que usted mencionó en de las charlas que había hecho sobre nosotros, nuestra consulta es esta separación de los tipos de naturalezas de este, que la realización llegó a usted.

Al usar Redux y descubrir que esto no se siente ergonómico o correcto, o simplemente mientras se trabaja 

en react-query 

[00:06:00] Tanner: Definitivamente vino a mí antes. Empecé a soñar, reaccionar, consultarlo. Eso fue algo donde, ya sabes, yo, yo, yo sabía que el servidor, el estado y el estado del cliente, ni siquiera tenía ese vocabulario en el momento, pero yo sólo sabía que había una diferencia muy núcleo entre mis datos asíncronos y mi síncrono. Y cuando vi esa diferencia en la ergonomía, como usted dijo, y cómo acceder a los datos y esperar que se comporten.

Un día revisé mi tienda Redux y dije, separemos todo en dos lugares. Sí, claro. Tomemos todo nuestro, todo el estado de mis servidores. Y fue entonces cuando empecé a llamarlo estado de servicio y lo puse encima. Cualquier cosa que tenga que ver con el servidor y que no sea de mi propiedad, eso es sólo un caché.

Pongámoslo aquí en esta parte y todo lo demás que poseo en el cliente. Pongamos aquí en esta otra parte. Y después de separar ambos, me sorprendió ver lo poco que Estaba realmente en mi tienda Redux o estaría en mi tienda Redux si hubiera eliminado todo el almacenamiento en caché de ella.

Y cuando vi que era, fue asombroso, es sorprendente, pero también algo esperado. Y lo que es impresionante es que con esa distinción que tenía entonces. Fui capaz de empezar a pensar en ellos de manera diferente y, ya sabes, por lo general con, con síncrono frente a asíncrono, sus métodos de lectura y actualización de los datos, que varían de manera diferente allí, usted sabe, las cosas síncrono, incluso hasta la API y la sintaxis que se utiliza en JavaScript es muy diferente.

Puedes leer sincrónicamente y escribir sincrónicamente. Y ya sabes, eso no es un gran problema, pero con las cosas asíncronas, hay mucho más de una farsa involucrados también, para conseguir que funcione. Una vez que te metes en las promesas, entonces todo tiene que convertirse en una promesa y async await. Y una vez que entras en async await, ya sabes, no tienes garantías de cuándo.

Los datos van a volver o la frecuencia con la que van a volver. Así que tan pronto como se empieza a almacenar en caché en absoluto, se hace más difícil y Redux estaba bien para cobrar en la medida en que se podía gestionar de manera efectiva. Y mi primera implementación de react query vivió dentro de Redux.

Y yo. Tenía ganchos especiales que utilizaría para leer los datos de Redux, de una tienda. Y esos ganchos desencadenarían automáticamente el ciclo de vida que tiene la consulta de Reactor. Y luego me di cuenta de que realmente, no había ninguna razón por la que los datos tenían que vivir en Redux. Así que lo trasladé a su propio almacén, su propio proveedor, y todo era personalizado.

Y entonces gran parte de la lógica comenzó a moverse en esa tienda personalizada que había construido. Y eso fue básicamente el comienzo de la consulta react repo, allí mismo.

[00:09:05] Matias: El mundo React venía de lejos con el camino Redux similar 

implementaciones 

alrededor de la misma idea de tienda global suena como React consulta es tan cómo relacionados, pero al mismo tiempo, me parece que es una bestia diferente completa, ¿verdad? Así que Redux y todos los otros paquetes similares por ahí son herramienta de gestión de estado global, pero consulta de react es no como una herramienta de gestión de estado 

es, es una gestión de caché 

herramienta, como un concepto diferente.

O puedes, puedes tal vez describir como tu visión sobre la diferencia 

entre 

gestión de estado estado global 

la gestión. Y, lo que 

realmente react-query 

hace

[00:09:46] Tanner: sí. Usted sabe, la gestión del estado para mí. Implica que tienes un control total sobre las cosas que pones en tu gestor de estado y, en su mayor parte, es cierto. 

Pero con, con el estado del servidor, usted realmente, usted, usted necesita aceptar en algún nivel que usted no está en pleno control de los objetos que usted está recibiendo de vuelta de la API, que es un almacenamiento en caché.

Tú, literalmente. Muy poco control sobre esos objetos. Y creo que las APIs que están diseñadas para estos gestores de estado global asumen que tienes el control total o al menos ponen mucha responsabilidad en ti como desarrollador para construir envoltorios y, ya sabes, lógica alrededor de estos gestores de estado global.

Eso te da más fiabilidad, ¿verdad? Así que no quieres tratar de leer de un valor antes de que haya vuelto del servidor. Así que ahora tenemos estados de carga involucrados, existe la posibilidad de que ciertas solicitudes fallen. Y ya sabes, ahora tienes un estado de error hay refetching de fondo. Así que si usted ya tiene algunos datos, pero usted es fetching en el fondo.

Ahora tienes un estado de búsqueda de fondo. Y entre esos tres estados, te metes en un montón de diferentes permutaciones de, ya sabes, cuál, cuál de esos estados es. Y hay un montón de contexto que va junto con todos esos estados. Todo eso es más o menos. Una máquina de estado muy sofisticada que tendrías que recrear en cualquier gestor de estado global que utilices.

Y esa máquina de estado no existe en el nivel de gancho, pero, y también no, también no existe sólo en, ya sabes, en una vez en la tienda, existe por consulta. Y ese es el concepto que creo que un montón de gente no entiende acerca de la consulta de reacción es que, ya sabes, sólo porque usted está escribiendo el uso de consulta de una tonelada en su aplicación no significa que eso es lo que muchas consultas se están creando.

Puedes abrir las herramientas de desarrollo y ver que todo está desdoblado y todas estas consultas son compartidas. Desde un lugar hasta el resto de tu aplicación. Y así, ya sabes, esa lógica para esa máquina de estado tiene que ser distribuida, ya sabes, y, y compartida entre todas estas diferentes instancias.

Es bastante sofisticado. bajo el capó para un concepto tan simple.

[00:12:15] Matías: Sí. Parece que sí. Pero al mismo tiempo, una de las cosas que se siente muy simple y tal vez en realidad se llama un video de ti hablando con

 Jason Langstrof, creo 

es que le muestre el código detrás de la gestión de claves, la gestión de la reina de las consultas, que estamos de acuerdo en que eso es en realidad muy simple. Simple, no fácil pero 

simple 

Creo que la gente tampoco entiende cómo se utilizan los datos que deben entrar en el 

clave de consulta 

matriz 

cosa. Así que 

¿podría describir por qué 

importante, se utiliza y cómo 

¿puedes construir uno? Como por ejemplo, si tengo. Usuario que no algo como esa fecha, que el cambio en la fecha y también 

en el id 

tienen tres parámetros, algo así. 

[00:13:06] Tanner: Claro. Así que cuando hablamos de una consulta, una consulta necesita tener alguna manera de identificarla de forma única y esa identificación única puede basarse en un par de cosas. Algunas de ellas están implícitas en la forma en que diseñas tu aplicación. Tendrás consultas para tipos de datos específicos. Una consulta para los usuarios o una consulta para, ya sabes, los equipos o espacios de trabajo en este caso, realmente simple de hacer la aplicación que tendría una consulta de producción a la vez la consulta de todas las tareas o una individual.

Sí. Así que hay contexto involucrado, pero también hay claves de especificidad en allí también. Así que estamos hablando de que el usuario o que hacer o que el equipo, ¿verdad? Estamos hablando de la identificación de las cosas que podría estar cambiando dependiendo de donde se utiliza en su aplicación. Podría ser una variable, ya sabes, como un ID de usuario después de que usted tiene otras cosas que pueden ir en como los metadatos que pueden ir en la identificación única de una consulta de metadatos.

Podría ser algo como la página. Si estás haciendo paginación o podría ser una visibilidad específica Que tienes en la llamada a la API que estás haciendo al backend. Tal vez usted está solicitando la vista previa de un objeto en lugar de la cosa completa, o tal vez usted está solicitando sólo un subconjunto de los campos QL gráfico y no todos ellos.

Así que también tienes detalles técnicos que van en los datos exactos que tu caché. Y cuando pones todo eso junto, tu contexto, tu información contextual, tu información de especificidad y tus metadatos, todo eso junto es lo que identifica de manera única una pieza de datos para reaccionar a la consulta, y para poner todo eso junto en un individuo.

Una sola cadena supondría mucho trabajo para el usuario. Tendrías que interpolar un montón de cosas diferentes y hash juntos y ponerlos en una cadena. Y si estuvieras a cargo de hacer eso, probablemente no lo harías de manera confiable o consistente a través de tu aplicación muy fácilmente 

[00:15:14] Matías: En algún momento meteremos la pata. 

[00:15:15] Tanner: ¿Cierto? Y luego te metes en funciones de hash y nadie quiere tener que hacer eso. Así que el manejo de la clave de consulta dentro de la consulta de reacción es inteligente al respecto. Las reglas son bastante seguras. Puede, ya sabes, en el nivel superior, una clave de consulta puede ser sólo una cadena si quieres mantener las cosas simples. Y, ya sabes, es como, aquí está la consulta de hacer.

Puedes pasar una cadena llamada todos o puede ser un array. Y tan pronto como se convierte en una matriz, puede ser una matriz de básicamente cualquier cosa, siempre y cuando sea JSON serializable. Y esto es, esto es útil porque, ya sabes, si usted, si usted tiene un todo individual que, usted necesita para obtener su consulta. La clave puede ser una matriz.

Todos como el primer elemento de cadena en la matriz. Y el segundo elemento podría ser el entero o el ID del, para hacer. Y bajo el capó, que va a ser serializado en una cadena. Eso va a ser utilizado para identificar de forma única esta consulta y eso es genial porque el orden importa y puedes ser tan específico como quieras.

Así que si cambias el puntal en tu "todo". Eso dice que estás viendo una tarea diferente. Cambiará la clave de consulta. Y eso es también algo que react query utiliza para saber cuándo actualizar o cuándo hacer nuevas consultas es cuando es la clave de consulta, cambiando la clave de consulta cambiando. No es sólo un identificador de los datos únicos, pero también es un identificador de su intención de cualquiera.

Descartar una consulta antigua que ya no se utiliza o introducir una nueva consulta en el sistema que aún no existe. Así que a partir de ahí, eso cubre la mayor parte de lo básico. Puedes tener tantos elementos en las claves de consulta que quieras. La otra cosa interesante es que al mantener el soporte JSON, está estructurado por defecto.

No es necesario tener una estructura específica para las cuerdas. Pero el orden sí importa. Excepto para los objetos. Así que técnicamente podrías pasar un objeto de metadatos a una clave de consulta, y ese objeto va a recibir un hash bajo el capó. También va a ser encadenado en la cola de consulta, pero hacemos los objetos de una manera un poco diferente.

Los objetos son una cadena de lucha en un determinista. Así que todo lo que significa es que antes de hash de un objeto en una cadena, que ordenar todas las propiedades en orden alfabético para que cada vez que se pasa en una propiedad o un objeto para reaccionar consulta, las propiedades van a ser stringify en el mismo orden exacto.

Y eso es importante para poder detectar cambios en asegurar la consistencia. Así que tomar todo eso es definitivamente algo que un usuario no va a querer tener que preocuparse. Y es por eso que es fácil decir aquí es una matriz. Puedes poner lo que quieras como clave del array como clave de consulta en estas ranuras del array, y nosotros nos encargaremos del resto por ti.

[00:18:10] Matias: entonces como, no se porque tal vez 

porque estaba 

escribirlo sobre 

Esto 

la clave de consulta se siente clave prop en cualquier lista de reacción 

cosa.

Habla de eso y habla de 

el caché 

y luego mezclas el gráfico QL 

en el centro y 

personas 

tienden a confundir tal vez 

algunas de las características que Apollo 

ofrece 

ofrecen un caché normalizado 

reaccionar. consultar 

no significa lo que significa 

para el usuario final? El usuario desarrollador. 

[00:18:41] Tanner: Ya sabes, esa es una buena pregunta. Creo que al principio, cuando mostré la consulta de reacción a un montón de gente, son como, oh, así que es como Apolo. Y, y yo era como, ah, algo así. Y realmente lo que viene a ser es que ese Apolo ha estado anunciando dos cosas separadas como una sola durante mucho tiempo. Ya sabes, hay una gran diferencia, al menos para mí, entre un cliente de gráficos QL y un sistema de caché.

Sí.

Así que el, el sistema de caché en sí es, ya sabes, es para Apollo, tienen su propio sistema de caché bajo el capó. Sí, es cierto. Ya sabes, olvídate de las características de la gráfica QL. Estamos hablando de un sistema de almacenamiento en caché. Si sacaras el gráfico QL de Apollo, probablemente se parecería un poco a algo como react query.

Y durante mucho tiempo, al menos desde mi punto de vista, la gente ha estado confundiendo las ventajas del QL de gráficos con el cliente de Apollo, porque el cliente de Apollo era relativamente inteligente y, ya sabes, puede hacer de duping e invalidación y auto normalización y cosas así. Cosas muy buenas. Y, ya sabes, durante mucho tiempo la gente decía, bueno, oh sí, tienes que usar graph QL porque nosotros en graph QL te daremos una duplicación debida y te dará, y como que empiezan a nombrar características que son realmente más una característica de Apollo y no de graph QL.

Y hay un gran artículo por ahí de Swizec Teller. Y habla de, ya sabes, ¿por qué crees que necesitas QL gráfico? No puedo recordar el título exacto, pero es como, por qué. Por qué w por qué crees que quieres gráfico QL, pero realmente reaccionar consulta hará la mayor parte del trabajo para usted. Y, y eso es lo que se reduce a que la gente ha confundido los beneficios de los dos durante mucho tiempo.

Y cuando, cuando se trata de ello, la mayor diferencia ahora entre el uso de consulta de reacción con QL gráfico, o el uso de un gráfico diferente, QL cliente en sí va a venir a la normalización. Así que react query la caché subyacente en react query es básicamente un almacén de valores clave, ¿verdad? Acabamos de hablar de las claves de consulta y esas son las claves de este almacén de valores clave, siendo los valores los datos que llegan.

Así que si tienes muchas consultas interconectadas que dependen unas de otras. Graph QL lo hace. A veces te puedes preguntar, bueno, ¿por qué, por qué esta otra consulta no se actualiza cuando esta otra consulta se actualiza? Y es porque no hay un esquema en la consulta de reacción y para bien o para mal. Esto, ayuda a mantener las cosas simples.

Y sin un esquema, no tienes que preocuparte. Ya sabes, acerca de la definición de ese esquema por adelantado, puede tipo de moverse rápidamente y se escala relativamente bien, incluso para los proyectos más grandes y la mayoría de los proyectos que están utilizando resto será capaz de utilizar la consulta de reacción muy bien. Ya sabes, realmente cuando te metes en los sistemas que tienen tipo de.

Esquema que está interconectado ese gráfico como esquema que QL gráfico es tan bueno en, en la obtención y la navegación. No significa necesariamente que las consultas de reactores vayan a fallar. Sólo significa que no vas a tener. Invalidaciones automáticas y normalización automática que obtienes con una herramienta como Apollo o Urql.

Y son, son grandes herramientas. Si usted sabe, usted está usando QL gráfico para todo y su esquema es sólido y quiere comprar en esos marcos, entonces por todos los medios que son grandes herramientas. Pero hay algo que decir acerca de tener. Datos y un sistema que es lo suficientemente simple para modelar dentro de un almacén de valores clave.

Parte de eso lo conseguimos con la API de react query. La API es lo suficientemente flexible como para darte las herramientas que necesitas para invalidar y mantener actualizadas partes específicas de tu aplicación sin tener la, ya sabes, sin tener que implementar la carga cognitiva de un esquema. Tú mismo, como desarrollador, obviamente sería genial si hubiera un esquema, pero cuando no lo hay, no puedes esperar que ningún desarrollador sepa, vale, cuáles son todas las cosas relacionadas que esta mutación de QL del gráfico podría tocar y, ya sabes, y ese es, ese es un gran caso de uso para la normalización

Y eso no significa necesariamente que no estamos mirando a la normalización. Nosotros, hemos estado investigando cómo podríamos implementar la normalización opt-in en, en la consulta de reacción durante los últimos meses. Y es prometedor. Es realmente difícil. Porque la introducción de un esquema en una herramienta sin esquema es una gran empresa.

Así que queremos asegurarnos de tener cuidado con eso. Es algo que tenemos en nuestro radar, pero.

[00:23:32] Matías: El desarrollo continuo de React-query y el aumento de sus características. Eso significa que todavía hay mucho 

manera de mejorar 

y ser mejor en nuestro equipo. Utilizamos react query con 

graphql 

solicitar al cliente para 

graphql. Eso es sólo una llamada de correo. Nada. 

[00:23:49] Tanner: Yep.

[00:23:51] Matias: Y sin embargo, no necesito del esquema de la 

normalización, aunque tenemos un montón, mucho 

de la simulación de la consulta, 

porque es una especie de ayuda para mantener las cosas simples. Como usted dijo, como estoy mutando este grupo en particular. Elijo no mutar o actualizar cualquier otra consulta que no esté relacionada 

con el 

datos actualmente 

visto un usuario, que 

no tiene sentido que las cosas sean, son otras 

ruta 

y se consultará cuando el usuario vaya 

a esa ruta.

No, es 

No importa. Es muy simple en ese sentido. 

[00:24:29] Tanner: Sí, creo, creo que la mayoría de las aplicaciones pueden ser simples como que si estamos siendo Frank. Hay muy pocas situaciones que he oído a la gente describir que realmente se beneficiaría del nivel de normalización que estamos hablando. Un buen ejemplo es. Como un feed de Twitter o un tweet deck tipo de una situación.

Ya sabes, si tienes varias líneas de tiempo de tweets bajando por la pantalla y pulsas el botón del corazón en uno de ellos, y ese mismo tweet está dentro de las otras columnas en tu pantalla con la consulta de reacción, tendrías que volver a obtener esas otras consultas o, siendo optimistas, actualizarlas para ver ese corazón rojo aparecer en los otros, en los otros tweets con una normalidad.

Sistema, verías ese corazón rojo iluminarse inmediatamente en todas las demás columnas también. ¿Es eso un cambio de juego? No lo sé. Depende de los requisitos de tu aplicación. No creo que, al menos en los productos que he construido, tener ese nivel de granularidad de las actualizaciones nunca ha merecido la pena el coste de usar una caché normalizada.

[00:25:45] Matías: Y digamos que Nozzle está construyendo cuadros de mando complejos con visualizaciones de datos complejas. Así que no estás hablando de la obligación simple en absoluto. 

[00:25:54] Tanner: No. Pero es un, es un tipo diferente de complejo, ¿verdad? Gráfico QL y el efectivo normalizado. Creo que esas son herramientas diseñadas para resolver modelos de datos horizontalmente complejos, ¿verdad? Donde tienes muchos modelos interconectados y activos compartidos a través de un montón de cosas. Boquilla. Definitivamente se inclina más hacia la profundidad, la complejidad de la profundidad y no la amplitud de la complejidad.

Así que estamos obteniendo grandes cantidades de datos a través de solicitudes individuales, ya sabes, sus, sus consultas que se están ejecutando en gran consulta. Escaneando terabytes de datos y volviendo con, ya sabes, cientos o quizás miles de filas que necesitamos presentar al usuario. Así que, hay diferentes problemas, espacios, en lo que respecta al modelado de datos, pero

[00:26:46] Matias: Eso es una especie de última pieza de consulta bien reaccionar publicó la V3 hace meses. Eso es en realidad una división en el paquete. Ahora tienes react query core, el paquete core que maneja la lógica y todo lo demás es una especie de plugin, como algo opcional que puedes añadir, como el React, Part itself que te ayuda a definir más características como opt-in, como mencionaste para la normalización, para el futuro. 

[00:27:14] Tanner: Sí, absolutamente. Hemos tratado de desglosar las características principales de la consulta de react en estos diferentes ya sabes, el árbol de división de código sacudió partes. Lo que tiene que ser capaz de mantener el paquete de tamaño bajo, pero también mantener las cosas modulares. Así que en el futuro, si introducimos algún tipo de sistema normalizado, es muy seguro asumir que sería opcional y vendría en un submódulo diferente que podrías importar por sí mismo.

Y, ya sabes, algunas cosas que se trasladó en el paquete, como reaccionar, herramientas de desarrollo de consulta y algunas cosas que dividimos. Así que sí, es, creo que es una buena técnica y, y sí, tiene sus propias compensaciones. Pero en su mayor parte, hemos sido capaces de separar la lógica y mantenerla muy modular.

[00:27:59] Matias: bien. Bueno, creo que tal vez la última pregunta es que te vi y en realidad te escucho mucho en el espacio de Twitter. mientras que usted conmutó, hablando de reaccionar, tabla de tipos de consulta. Abrir el espacio para que la gente pregunte cosas, ¿Cómo va eso? Ha sido agradable que, que usted comparte una gran cantidad de conocimientos allí.

No sé cuánto tiempo estás haciendo esto.

[00:28:29] Tanner: Quiero decir, sobre todo comenzó como una manera de mantenerme despierto. Me gusta despertarme temprano y conducir al trabajo muy temprano. Y en su mayor parte, no me canso después de que me despierto. Pero los primeros días y la semana en que estaba haciendo eso, yo estaba un poco cansado. Así que yo estaba, yo estaba usando como una manera de mantener a mí mismo comprometido y, y se encendió mientras yo, mientras que la unidad por la autopista.

Sí. Y para el final, sí ayudó. Definitivamente. Y ahora disfruto haciéndolo para obtener mi dosis de conversación del día. No tengo la oportunidad de interactuar con un montón de otros desarrolladores en persona. Al menos los desarrolladores frontales. Tengo un empleado aquí en la boquilla, que es uno de mis devs junior, pero fuera de él, yo, ya sabes, no tengo mucho más que sólo hablar con otras personas en Twitter.

Así que creo que es divertido para llegar y como permanecer conectado con el, ya sabes, las personas que están en todo el mundo. Aprendiendo TypeScript, aprendiendo, JavaScript, usando mi biblioteca. Poder conocerlos mejor y hablar con ellos y darles la oportunidad de conocerme a mí también. Y sí, es, es simplemente divertido.

Así que,

[00:29:39] Matías: Sí. Yo escucho algunos de ellos y es muy divertido. Es muy perspicaz. Así que porque muchas preguntas son realmente buenas que te llevan a tu conocimiento. No es ha sido útil para terminar este episodio, Tanner, me gustaría que usted pregunta, si usted tiene algo que como un enchufe sin vergüenza que desea compartir con el. 

[00:30:02] Tanner: Sí. Tengo un par, uno de ellos es que si usted utiliza react query o react table en su empresa, me encantaría ayudarle a buscar un patrocinio con su empresa para el Tannstack. Esa es una de las mayores razones. He sido capaz de mantener la construcción de software de código abierto a través de, ya sabes, en los últimos años es que he tenido un poco de patrocinios aquí y allá que me mantienen en marcha, que han sido capaces de mantenerme motivado y, ya sabes, ayudar a mi familia y, y otros desarrolladores que conozco también.

Así que sí, yo, yo estaría más que feliz de hablar con cualquiera. El patrocinio y, y también hay un montón de ventajas interesantes que vienen con los patrocinios también. Hay horas de consulta gratuitas y, y vales de cursos gratuitos para mi curso react query essentials, que es otra cosa que supongo que podría enchufar como si, si realmente te gusta react query.

¿Quieres saber más sobre él? Y leer la documentación, no es suficiente para ti. Puedes mirar en tomar mi curso esencial de consulta de react. Puedes ir a learn.tannstack.com y registrarte allí. Acabo de añadir dos nuevas opciones de precios que son como un videoclub de la vieja escuela. Sí.

Así que, si quieres pagar menos, puedes, puedes alquilar el curso por tres días o 30 días y pagar mucho menos si 

[00:31:25] Matias: más rápido. 

[00:31:27] Tanner: sí.

[00:31:28] Matias: Y sí, los enlaces para eso estarán en las notas del programa para terminar. ¿Tienes algo que quieras fuera del mundo de la tecnología, fuera de lo que sea, esto sólo tú Tanner, qué te gusta recomendar a cualquiera que te escuche? Como algo que estás viendo, leyendo algo que te gustaría hacer?

Cualquiera que sea nuestra recomendación de Linsley a la audiencia

[00:31:52] Tanner: Realmente no, tenemos muchas recomendaciones. Me gusta eso. Me gusta que he escuchado mucha música también. No voy a clavar a un solo género o canción, ya sabes, yo diría que sólo los viajes. Esa es mi mayor recomendación, viajar. Cuando puedas pasar tiempo con tu familia, cuando puedas. Esos son mis dos mayores objetivos en la vida: estar con mi familia tanto como sea posible y viajar y ver el mundo.

Y, en definitiva, sé amable con todos los que conozcas.

[00:32:25] Matías: Eso es cierto. Eso es bueno, una buena recomendación de todos modos, ser siempre amable te va a ayudar con hacer amigos conocer gente aumentar tu propia felicidad. ¿No es así? 

[00:32:37] Tanner: Absolutamente.

[00:32:38] Matias: Así que gracias Tanner, , gracias por estar aquí. Gracias por ser un invitado en cafe con tech.

[00:32:45] Tanner: Usted apuesta. Ha sido increíble.

[00:32:48] Matías: Sí, ha sido perspicaz. Hablar de una consulta de estado y reacción. Así que si quieres aprender más, ya lo oyes. Mira el enlace en las notas del programa y visita el sitio de TannStack para aprender más sobre react-query y comprar el curso. Y si eres una empresa que utiliza react query, este es el momento de patrocinar una buena pieza de software que probablemente te está dando un montón de dólares. sí, nos escuchamos en el próximo episodio la próxima semana. Sí. 

[00:33:17] Tanner: Por todo el mundo.



English
 

[00:00:00] Matias: Welcome to a new episode of cafe con tech in this special  

season in English  

today with me is the open sorcerer itself. Co-founder of Nozzle creator of react-query Tanner Linsley Welcome Tanner.  

Thank  

you for being here.  

[00:00:15] Tanner: Yeah, you bet. 

[00:00:15] Matias: In case people don't yet get to know you. And can you help out us with us, maybe a little introduction for yourself.  

[00:00:23] Tanner: Sure. I've been professionally programming for about. Eight nine years now. And like you said, I have a startup called nozzle. You can find a set nozzle.io. And for the last seven years we've been we've been working on reverse engineering, Google search rankings. So we go out and crawl all of the search rankings that matter to your company. 

And we come back and present you that day. You know, with a big data analytic system and show you where you rank and where your competitors rank and why people rank where they do. So, yeah, it's, it's been a lot of fun. It's been a technical challenge and together with those challenges. Has brought the unique opportunity to build open source software for my own startup that I can then use to solve those problems. 

And that's where a lot of my open source projects have come from. 

[00:01:25] Matias: Actually your open source work is become to be 

 as tannstack because  

you actually have a lot of things to, to share with react world. And one of those in particular is react query, right? So it's kind of a, your biggest. Success in numbers source, or at least the package that is  

being most use it.  

And I think people know at least the audience that works with react. No no about real equity, but can you kind of describe a bit, what is the magic behind react-query What is the reason maybe that becomes so successful between the react users?  

[00:02:06] Tanner: Yeah. I think from very early on working with react fetching data. From any asynchronous source was a bit of a challenge. I remember, you know, from the very beginning of learning react, I learned Redux and Redux is great and it's a great global state manager. But at the end, the day I needed to just fetch a lot of data from the backend. 

You can imagine. Building a product that, you know, we have an API that we're showing lots of data to our users and working with a lot of crud API APIs. That was something that I needed to do a lot. And I remember like it wasn't, it was probably only like a, you know, a couple hours into learning. That I said, well, how can I fetch data? 

And the answer was, well, you need to use these things called thunks. I was like, all right, can I just use promises? And it's like, yes, you can. But they have to be inside of this thunk. And you have to give those things a place to live inside of your Redux store. And it's all global. And it's like, okay, cool. 

Like I just kind of going through the motions. That's just how I learned. Kind of like many other people. But as time went on, you know, their constraints grow instead of bigger applications. And eventually I needed, you know, more of a robust system that was going to keep my data. In my application up to date as often as possible and make mutations and reading that data really flexible. 

And these syntax for reading asynchronous data in Redux. Well, it's not my favorite. So I kind of just stuck with Redux for a long time until hooks came out. And when hooks came out, I saw a unique opportunity to use the new syntax of hooks to make working with asynchronous data easier. So internally. 

at Nozzle. I started building a solution that would become known as react query. And I used it internally at nozzle for a couple of months until it was ready to open source. So after I had built react query internally at nozzle, I released it back at the end of 2019. And yeah, I mean, I need. And that's why I built it because I wanted something that was going to just make my life easier and let me work faster. 

So apparently lots of other people needed react query too, because after I released it, it got a lot of attention from other developers who wanted to help contribute to it. People who wanted to build tools on top of it. Even other frameworks that wanted to use it internally. So it has gotten a lot of attention, good attention and help from some amazing developers. 

And you know, I eventually wrote a course about it. So I have a video course called react, query essentials, and, you know, there's tons of examples and lots of documentation, and it's become a very mature. Library in the react ecosystem. So. 

[00:05:13] Matias: I think saw. 

an implementation  

or at least they borrowed the name and some of the implementations, of react-query into Svelte.  

Like  

svelte query using the react query core packets. So it's kind of amazing that it's kind of spreading through the entire JavaScript ecosystem. One thing that resonates a lot with me with, eh, react query is one of the things that you mentioned in of the talks that you had made about we, our query is this separation of the types of natures of this, that realization came to you. 

By using Redux and figure out that this doesn't feel ergonomic or correct, or just while working  

on react-query  

[00:06:00] Tanner: Definitely came to me before. I started dreaming up, react, query it. That was something where, you know, I, I, I knew that server, state and client state, I didn't even have that vocabulary at the time, but I just knew that there was a very core difference between my asynchronous data and my synchronous. And when I saw that difference in ergonomics, like you said, and how I access that data and expect it to behave. 

I went through my Redux store one day and I just said, let's separate everything into two places. Right. Let's take all of our, all of my servers state. And that's when I kind of started calling it service state and let's put it over. Anything that has to do with the server and that I don't own, that's just a cache. 

Let's put it over here in this part and everything else that I do own on the client. Let's put over here in this other part. And after I separated them both out, I was astounded to see how little. Was actually in my Redux store or would be in my Redux store if I had just removed all of the caching from it. 

And when I saw that it was, it was astounding, it's startling, but also kind of expected. And what's awesome is that with that distinction that I then had. I was able to start thinking about them differently and, you know, generally with, with synchronous versus asynchronous, your methods of reading and updating that data, they vary differently there, you know, the synchronous stuff, even down to the API and syntax that you use in JavaScript is very different. 

You can read synchronously and write synchronously. And you know, that's not a big deal, but with asynchronous stuff, there's just so much more of a charade involved too, to get it working. Once you get into promises, then everything has to become a promise and async await. And once you get into async await, you know, you have no guarantees of when. 

The, the data is actually going to come back or how often it's going to be coming back. So as soon as you start caching at all, it it gets more difficult and Redux was fine to cash in as long as you could manage it effectively. And my actually my first implementation of react query lived inside of Redux. 

And I. I had special hooks that I would use to read the data from Redux, from a store. And those hooks would kind of automatically trigger the life cycle that react query has. And then I found out that really, there was no reason the data needed to live in Redux. And so I moved it out into its own store, its own provider, and it was all custom. 

And then a lot of the logic started moving into that custom store that I had built. And that was basically the beginnings of the react query repo, right there. 

[00:09:05] Matias: React world came from a long with path Redux similar  

implementations  

around the same idea of global store sounds like React query is so how related, but at the same time, it feels to me that it's a complete different beast, right? So Redux and all of the other similar packages out there are global state management tool, but react query is not as a state management tool  

is, is a cache management  

tool, like a different concept. 

Or can you, can you maybe describe like your vision about difference  

between  

state management global state  

management. And, what  

actually react-query  

does 

[00:09:46] Tanner: yeah. You know, state management to me. Kind of implies that you have total control over the things that you're putting into your quote unquote state manager and for the most part, that's true.  

But with, with server state, you really, you, you need to accept at some level that you're not in full control of the objects that you're getting back from the API, that you're a caching. 

You, you literally. Very little control over those objects. And I think the API APIs that are designed for these global state managers assume that you have full control or at least they put a lot of responsibility on you as the developer to build to build wrappers and, you know, logic around these global state managers. 

That give you more reliability, right? So you don't want to try and read from a value before it's come back from the server. So now we have loading states involved there's the potential for certain requests to fail. And you know, so now you have an error state there's background refetching. So if you already have some data, but you're fetching into the background. 

Now you have a background fetching state. And between those three states, you get into a lot of different permutations of, you know, which, which one of those states is it. And there's a lot of context that goes along with all those states. All of that is more or less. A very sophisticated state machine that you would have to recreate in any global state manager that you use. 

And that state machine doesn't exist at the hook level, but it, and it doesn't also, it also doesn't exist just at, you know, in one time in the store, it exists per query. And that's the concept that I think a lot of people misunderstand about react query is that, you know, just because you are writing use query a ton in your app doesn't mean that that's how many queries are getting created. 

You can open up the dev tools and see that everything is de duplicated and all of these queries are shared. From one place out to the rest of your application. And so those, you know, that logic for that state machine has to be distributed, you know, and, and shared between all these different instances. 

It's a pretty sophisticated. Under the hood for such a simple concept. 

[00:12:15] Matias: Yeah. Sounds like it. But at the same time, one of the things that feels really simple and maybe actually is called a video of you talking with 

 Jason Langstrof, I think  

is that you show that him the code behind key management, the query queen management, that we agree that that is actually really simple. Simple, not easy but  

simple  

I think that people also misunderstood about how they are used what data should go into the  

query key  

array  

thing. So  

can you kind of describe why  

important, is used and how  

you can build one? Like for example, if I have. User that not something like that date, that change on the date and also  

on the id  

have three parameters, something like that.  

[00:13:06] Tanner: Sure. So when we're talking about a query, a query needs to have some way to uniquely identify it and that unique identification can be based on a couple of things. Some of them are implicit to the way you design your application. You'll have queries for specific types of data. A query for a users or a query for, you know, teams or workspaces in this case, really simple to do app you'd have a produce query to both query all of the to-dos or an individual one. 

Right. So there's context involved, but then there's also specificity keys in there as well. So we're talking about which user or which to do or which team, right? We're talking about the ID of the things that might be changing depending on where you use it in your application. It could be a variable, you know, like a user ID after that you have other things that can go into like metadata that can go into uniquely identifying a query metadata. 

It could be something like the page. If you're doing pagination or it could be a specific visibility. That you have on the API call that you're making to the backend. Maybe you're requesting it preview of an object instead of the full thing, or maybe you're requesting only a subset of the graph QL fields and not all of them. 

So you have also technical details that go into the exact data that your caching. And when you put all that together, your context, your contextual information, your specificity information and your metadata, all of that together is what uniquely identifies a piece of data for react query, and to put all that together into an individual. 

Just one string would take a lot of work for the user to do. You'd have to interpolate a bunch of different things and hash them together and put them into a string. And if you were in charge of doing that, You probably wouldn't do it reliably or consistently across your application very easily  

[00:15:14] Matias: We will mess up at some point.  

[00:15:15] Tanner: Right? And then you get into hashing functions and no one wants to have to do that. So the query key handling inside of react query is smart about it. The rules are pretty safe. It can, you know, at the top level, a query key can be just a string if you want it to keep things simple. And, you know, it's just like, here's the to do's query. 

You can pass a string called todos or it can be an array. And as soon as it becomes an array, it can be an array of basically anything as long as it's serializable JSON. And this is, this is helpful because, you know, if you, if you have an individual todo that, you need to fetch your query. Key can be an array. 

Todos as the first string item in the array. And the second item could be the integer or ID of the, to do. And under the hood, that's going to get serialized into a string. That's going to be used to uniquely identify this query and that's great cause order matters and you can be as specific as you want. 

So if you change the prop on your todo. That says you're looking at a different to do. It will change the query key. And that's also something that react query uses to know when to refresh or when to make new queries is when is the query key, changing the query key changing. Isn't just an identifier of the unique data, but it's also an identifier of your intent to either. 

Discard of an old query that you're no longer using or to introduce a new query into the system that doesn't exist yet. So from there, so that kind of covers most of the basics. You can have as many items in the query keys you want. The other interesting thing is that by keeping it JSON supported, it's structured by default. 

You don't have to have a specific structure for your strings. But order does matter. Except for objects. So you could technically pass an object of metadata to a query key, and that object is going to get hashed under the hood. It's going to also get stringify into the query queue, but we do objects a little differently. 

Objects are a string of fight in a deterministic. So all that means is that before we hash an object into a string, we sort all of the properties in alphabetical order so that every single time you pass in a property or an object to react query, the properties are going to be stringify in the exact same order. 

And that's important to be able to detect changes in ensure consistency. So take all of that's definitely something a user's not going to want to have to worry about. And that's why it's easy to just say here's an array. You can put whatever you want as the array key in as the query key in these array slots, and we'll take care of the rest for you. 

[00:18:10] Matias: so how, I don't know why maybe  

because I was  

writing it about  

it it.This  

query key feels key prop on any react list  

thing. 

Talk about that and talk about  

the cache  

and then you mix graph QL  

in the middle and  

people  

tend confuse maybe  

some of the features that Apollo  

offers  

they offer normalized cache  

react. query  

doesn't what it mean  

for the final user? The developer user.  

[00:18:41] Tanner: You know, that's a good question. I think in the beginning, when I showed react query to a lot of people, they're like, oh, so it's like Apollo. And, and I was like, ah, kind of. And really what it comes down to is that that Apollo has been advertising two separate things as one for a very long time. You know, there's, there's a big difference at least to me, between a graph QL client and a caching system. 

Right. 

So the, the caching system itself is, you know, is for Apollo, they have their own caching system under the hood. Right. You know, forget about the graph QL features. We're talking about just a caching system. If you were to take the graph QL out of Apollo, It would probably resemble a little bit something like react query. 

And for a long time, at least from my view, people have been conflating the advantages of graph QL with Apollo's client, because Apollo's client was relatively smart and, you know, it can do de duping and invalidation and auto normalization and things like that. Super cool stuff. And, you know, for a long time people said, well, oh yeah, you need to use graph QL because we at graph QL will give you a due duplication and it will give you, and they kind of start naming off features that are really more a features of Apollo and not of graph QL. 

And there's a great article out there from Swizec Teller. And he talks about, you know, why you think you need graph QL? I can't remember the exact title, but it's like, why. Why w why you think you want graph QL, but really react query will do most of the job for you. And, and that's what it comes down to is that people have conflated the benefits of those two for a really long time. 

And when, when it comes down to it, the biggest difference now between using react query with graph QL, or using a different graph, QL client itself is going to come down to normalization. So react query the underlying cache in react query is basically a key value store, right? We just discussed the query keys and those are the keys of this key value store, the values being the data that comes through. 

So if you have a lot of interconnected interrelated queries that rely on one another. Graph QL does. Sometimes you might find yourself asking, well, why, why doesn't this other query update when this other query updates? And it's because there's no schema in react query and for better or worse. It, it helps keeps things simple. 

And without a schema, you don't have to worry. You know, about defining that scheme up front, you can kind of get moving quickly and it scales relatively well, even for larger projects and most projects that are using rest will be able to use react query just fine. You know, really when you get into systems that have kind of. 

Schema that's interconnected that graph like schema that graph QL is so good at, at fetching and navigating. It doesn't necessarily mean that react queries going to falter. It just means that you're not going to have. Automatic invalidations and automatic normalization that you get with a tool like Apollo or Urql. 

And they're, they're great tools. If you know, you're using graph QL for everything and your schema is solid and you want to buy into those frameworks, then by all means they're great tools. But there is something to be said about having. Data and a system that's simple enough to model inside of a key value store. 

Some of that we get around to by with the API of react query. The API is flexible enough to give you the tools that you need to invalidate and keep specific parts of your app up to date without having the, you know, without having to implement the cognitive load of a schema. Yourself as the developer, obviously it'd be great if there was a schema, but when there's not you know, you can't expect any developer to know, okay, what are all of the related things that this graph QL mutation could touch and, you know, and that's, that's a great use case for normalization 

And that doesn't necessarily mean that we're not looking at normalization. We, we have been researching how we could implement opt-in normalization in, in react query for the last few months. And it's promising. It's really difficult. Because introducing a schema into a schema-less tool is a big undertaking. 

So we want to make sure that we're careful about that. It's something that we have on our radar, but. 

[00:23:32] Matias: React-query continuous development and increasing features. That means that there is still a lot of  

way to improve  

and be better in our team. We use react query with  

graphql  

request client for  

graphql. That just a Post call. nothing  

[00:23:49] Tanner: Yep. 
 

[00:23:51] Matias: And yet, I don't need of the schema of the  

normalization, even though we have a bunch, lot  

of query simulation,  

because it's kind of helped you keep things simple. As you said, like I'm mutating this particular group. I do choose not mutate or update any other query that is not related  

with the  

data currently  

seen a user, that  

doesn't make sense that things are, are other  

route  

and will be query when the user go  

to that route. 

No, it  

doesn't matter. kind of real simple in that way.  

[00:24:29] Tanner: Yeah, I think, I think most applications can be simple like that if we're being Frank. There's very few situations that I've heard people describe that actually would benefit from the level of normalization that we're talking about. A good example is. Like a Twitter feed or a tweet deck type of a situation. 

You know, if you have multiple timelines of tweets going down the screen and you hit the heart button on one of them, and that same tweet is inside of the other columns on your screen with react query, you would have to re fetch those other queries or optimistically, update them to see that red heart appear on the other, on the other tweets with a normal. 

System, you would see that red heart kind of light up immediately on all the other columns as well. Is that deal breaker a game-changer? I don't know. It just kind of depends on what your requirements are for your application personally. I don't really think that at least in my products that I've built, you know, having that level of granularity of updates has never really been worth the cost of using a normalized cache. 

[00:25:45] Matias: And let's say that Nozzle is building complex dashboard with complex data visualizations. So you're not talking about simple obligation at all.  

[00:25:54] Tanner: No. But it's a, it's a different kind of complex, right? Graph QL and the normalized cash. I think those are tools designed to solve horizontally complex data models, right? Where you have lots of interconnected models and shared assets across a lot of things. Nozzle. Definitely skews more to the depth, the complexity of depth and not not the breadth of complexity. 

So we're fetching large amounts of data through single requests, you know, their, their queries that are executing in big query. Scanning terabytes of data and coming back with, you know, hundreds or maybe thousands of rows that we need to present to the user. So there, there are different problems, spaces, as far as data modeling goes, but 

[00:26:46] Matias: That's kind of a last piece of well react query published the V3 months ago. That is actually a split on the package. Now you have react query core, the core package that handled logic and everything else is kind of a plugin, like optional thing that you can add, like the React, Part itself that helps you to define more features as opt-in, as you mentioned for the normalization, for the future.  

[00:27:14] Tanner: Yeah, absolutely. We have tried to break down the core features of react query into these different you know, code split tree shaken parts. What have you to be able to keep the bundle sized down, but also keep things modular. So in the future, if we do introduce some type of normalized system it's very safe to assume that that would be opt in and come in a different sub module that you could import on its own. 

And, you know, some things we moved into the package, like react, query dev tools and some things we split. So yeah, it's, I think it's a good technique and, and yeah, it has its own tradeoffs. But for the most part, we've been able to separate the logic and keep it very modular. 

[00:27:59] Matias: nice. Well, I think that maybe the last question is I saw you and I actually hear you a lot on Twitter space. while you commuted, talking about react, query typescript table. Open the space to people to ask things, How is that going on? It's been nice that, that you share a lot of knowledge there. 

I don't know how much time are you doing this? 

[00:28:29] Tanner: I mean, it mostly started as a way to keep me awake. I like to wake up early and drive into work really early. And for the most part, I don't get tired after I wake up. But the first few days and week where I was doing that, I was kind of tired. So I was, I was using it as a way to keep myself engaged and, and turned on while I while I drive down the freeway. 

Yeah. And for the end, it did help. Definitely. And now I kind of just enjoy doing it to just kind of get you know, my conversational dosage for the day. I don't get to interface with a lot of other developers in person. At least front end developers. I have one Employee here at nozzle, who is one of my junior devs, but outside of him, I, you know, I don't get very much other than just talking to other people on Twitter. 

So I think it's fun to reach out and like stay connected with the, you know, people who are all over the world. Learning TypeScript, learning, JavaScript, using my library. Just be able to get to know them better and talk with them and, and give them an opportunity to get to know me as well. And yeah, it's, it's just fun. 

So, 

[00:29:39] Matias: Yeah. I listen to a few of them and it's pretty fun. It's very insightful. So because so many questions are really good ones that get you to your knowledge. There is it's been useful to finish this episode, Tanner, I will like you ask you, if you have anything to like a shameless plug that you want to share with the.  

[00:30:02] Tanner: Yeah. I have a couple, one of them is if you use react query or react table at your company, I would love to help you pursue a sponsorship with your company for the Tannstack. That is one of the biggest reasons. I've been able to keep building open source software through, you know, over the past few years is that I've had a little sponsorships here and there that keep me going, that have been able to keep me motivated and, you know, help help out my family and, and other developers that I know as well. 

So yeah, I, I would be more than happy to talk to anybody. Sponsorship and, and there's also a lot of cool perks that come with sponsorships as well. There's free consultation hours and, and free free course vouchers for my react query essentials course, which is another thing I guess I could plug as if you, if you really like react query. 

You want to learn more about it? And reading through the documentation, isn't enough for you. You can look into taking my react query essential course. You can go to learn.tannstack.com and sign up there. I just added two new pricing options that are kind of like a old-school video store. Yeah. 

So, if you want to pay less, you can, you can rent the course for three days or 30 days and pay much less if  

[00:31:25] Matias: faster.  

[00:31:27] Tanner: yeah. 
 

[00:31:28] Matias: And yeah, the links for that will be in the show notes to finish. Do you have anything you want to outside of the tech world, outside of whatever the you thing, this just you Tanner, what do you like to recommend to anyone to listen to you? Like something you are watching, reading something that you'd like to do? 

Whatever our recommendation from Linsley to the audience 

[00:31:52] Tanner: I don't really, we have many recommendations. I like that. I like to I listened to so much music too. I'm not going to nail it down to a single genre or song, you know, I would say just travel. That's that's my biggest recommendation travel. When you can spend time with your family, when you can. Those are my two biggest goals in life is just to be with my family as much as possible and travel and see the world. 

And ultimately just be kind to everyone you meet. 

[00:32:25] Matias: That's true. That's good, a good recommendation anyways, to always be kindness will help you with making friends know people increase your own happiness. Right?  

[00:32:37] Tanner: Absolutely. 

[00:32:38] Matias: So Thank Tanner, , thank You for being here. Thank you for be a guest on cafe con tech. 

[00:32:45] Tanner: You bet. It's been awesome. 

[00:32:48] Matias: Yeah, it's been insightful. Talk about a state and react query. So if you want to learn more, you already hear it. Check the link in the show notes and visit TannStack site to learn more about react-query and buy the course. And if you're a company using react query, this is the moment to sponsor a good piece of software that it's probably giving you a lot of dollars. yeah, we hear us in the next episode next week. Yeah.  

[00:33:17] Tanner: By everybody.