React Query - Las partes malas

This ad is not shown to multipass and full ticket holders
React Summit US
React Summit US 2025
November 18 - 21, 2025
New York, US & Online
The biggest React conference in the US
Learn More
In partnership with Focus Reactive
Upcoming event
React Summit US 2025
React Summit US 2025
November 18 - 21, 2025. New York, US & Online
Learn more
Bookmark
Rate this content

React Query es una biblioteca popular para gestionar el estado asíncrono, más a menudo el estado devuelto por la obtención de datos. Su popularidad ha crecido significativamente en los últimos años, con casi el 20% de todas las aplicaciones React ahora utilizándola.
En esta charla, el mantenedor Dominik explorará el otro lado, los aspectos menos favorables de React Query y las situaciones en las que puede que no sea la mejor opción. Ninguna biblioteca es perfecta; cada elección implica compromisos. Al final de esta charla, tendrás una mejor comprensión de las limitaciones de React Query y por qué sigue siendo una opción atractiva a pesar de ellas.

This talk has been presented at React Day Berlin 2024, check out the latest edition of this React Conference.

Dominik Dorfmeister
Dominik Dorfmeister
30 min
13 Dec, 2024

Comments

Sign in or register to post your comment.
Video Summary and Transcription
React Query es una biblioteca popular con descargas semanales significativas y un sentimiento de usuario positivo. Puede tener compromisos como el tamaño del paquete, pero el tamaño real enviado es más pequeño. La optimización del tamaño del paquete se puede lograr exportando solo las características necesarias. El enfoque declarativo de React Query elimina la necesidad de soluciones personalizadas de obtención de datos. Ofrece almacenamiento en caché, duplicación de solicitudes, actualizaciones en segundo plano y más. RackQuery no admite el almacenamiento en caché normalizado, pero la reobtención después de la invalidación funciona bien. La visión de React incluye la arquitectura de suspense y los componentes del servidor. La documentación podría mejorarse con un flujo más estructurado. TensorStack Query puede ser una buena opción para las aplicaciones Next.js, pero no es necesario con los marcos maduros. Se discutieron los 10 conceptos de consulta y enrutador de pila. Combinar React Query con el almacenamiento en caché HTTP proporciona una solución de almacenamiento en caché robusta.
Available in English: React Query - The Bad Parts

1. Introducción a React Query

Short description:

React Query es amado por la comunidad por su experiencia de desarrollador y experiencia de usuario. Tiene un número significativo de descargas semanales y se utiliza en aproximadamente el 20% de las aplicaciones de React. Las encuestas muestran que la mayoría de los usuarios tienen una opinión positiva hacia React Query.

React Jets Introducción a React Query Una breve introducción a React Query React Query, la parte mala. Realmente espero que esto sea rápido, como una charla relámpago, de verdad, porque creo que en su mayoría React Query es simplemente genial. Creo que es amado por la comunidad por la experiencia de desarrollador y la experiencia de usuario que proporciona. Sé que es una afirmación audaz, así que intenté traer algunas pruebas para respaldarla.

Si miramos los números de descargas semanales en NPM, creo que React Query ha crecido mucho este año de casi 4 millones a 6 millones de descargas semanales. Creo que esos son números enormes, y si lo comparamos con los números de React, que también, React está creciendo fuerte, situándose en alrededor de 27 millones de descargas semanales, de repente la curva ya no parece tan impresionante, pero creo que aún podemos concluir de eso, que React Query se utiliza en aproximadamente el 20% de nuestras aplicaciones de React o en casi una de cada cinco aplicaciones. Algunas de esas aplicaciones, ellas mismas tienen millones de usuarios, como Sentry, Blue Sky o JetGPT, así que creo que React Query realmente obtiene mucha exposición.

Ahora, por supuesto, los números de descargas y el uso y la exposición no lo son todo, solo porque algo se use no significa realmente que sea querido. Así que tal vez una mejor manera sería mirar las encuestas. Está la encuesta State of Frontend 2024, que hizo la pregunta, ¿qué herramientas has usado para obtener datos en el último año? Ahora, no voy a ser quisquilloso aquí que React Query no es una biblioteca de obtención de datos, como Axios o Fetch, que están listadas aquí, pero detrás de esas, en realidad viene con un sentimiento muy positivo, porque solo al 2.8% de las personas que lo usaron no les gustó. Y State of React tiene una pregunta similar sobre utilidades para cargar y gestionar datos, y si agrupamos eso por sentimiento positivo, entonces TensorStripe Query en realidad sale en la cima con un poco más del 44%. Así que estoy realmente feliz de que a los desarrolladores parezca gustarles la biblioteca, porque la he estado manteniendo durante los últimos cuatro años.

2. React Query: Trade-offs and Bundle Size

Short description:

React Query tiene compensaciones y no siempre es la opción perfecta. Un inconveniente comúnmente mencionado es el tamaño del paquete, pero el tamaño real que se envía a los consumidores es mucho más pequeño de lo que se ve en npm.

Mi nombre es Dominic. Soy un ingeniero de software que vive en Viena, donde me uniré al equipo de plataforma frontend en Sentry el próximo mes. Y puedes encontrarme como TK Dodo en línea casi en todas partes, y también tengo un blog donde escribo sobre React y TypeScript, y por supuesto, React Query.

Ahora, he escrito y hablado mucho sobre por qué React Query es genial, y todavía creo que realmente lo es, pero, ya sabes, todo es una compensación. Y si usamos cualquier tecnología, generalmente es una buena compensación si lo que obtenemos a cambio vale más para nosotros o es mejor para nosotros que lo que estamos intercambiando. Ahora, creo que React Query es realmente una buena compensación para la mayoría de las situaciones, pero, por supuesto, hay casos donde podría no ser la mejor opción o la opción perfecta. Así que hoy, quiero hablar sobre estos casos, pero también tal vez desmentir algunos mitos que he escuchado sobre ello que hacen que parezca que es malo cuando en realidad tal vez no lo es. Así que tal vez la charla debería ser más como React Query, las compensaciones.

Bien. Comencemos con el primer punto, el elefante en la habitación, que es el tamaño del paquete. Que React Query tiene un tamaño de paquete enorme es algo que a menudo escucho como su mayor inconveniente. Y para llegar al fondo de eso, primero tenemos que establecer lo que no es el tamaño del paquete, porque no es lo que ves en npm, ¿verdad? Este es el tamaño que se envía a los desarrolladores cuando instalan la biblioteca.

3. Bundle Size Optimization

Short description:

Enviamos una versión especial heredada para empaquetadores más antiguos, lo que podría resultar en un tamaño mayor en Bundlephobia. Sin embargo, usar un empaquetador más moderno puede resultar en una salida más pequeña. Al exportar solo las características necesarias de RareQuery, el tamaño del paquete puede reducirse a menos de 10 kilobytes.

Y también enviamos algunos mods de código para las actualizaciones que tenemos. Este definitivamente no es el tamaño que se envía al consumidor.

Bien. Tampoco es lo que ves en Bundlephobia. Creo que Bundlephobia es un buen sitio para obtener una visión general rápida, pero no entiende ESM correctamente, lo cual creo... No, no creo que nadie haga eso. Pero, por ejemplo, enviamos una versión especial heredada para todos los empaquetadores, como Webpack 4, que no está tan optimizada, y Bundlephobia lo detecta. Así que lo que ves aquí también es todavía demasiado grande. Y si usas un empaquetador más moderno, obtendrás una salida más pequeña.

Así que realmente me gusta Bundle.js para obtener una buena visión general, porque simplemente construye lo que exportamos sobre la marcha con ESBuild, y luego muestra el impacto del tamaño. Así que si exportamos todo de RareQuery, llegamos a 12.4 kilobytes minzip. Ahora, eso no es nada, pero tampoco creo que sea mucho. Y si nos importa el tamaño, probablemente deberíamos usar compresión Brotli en lugar de gzip. Así que si hacemos eso, llegamos a unos agradables 12 kilobytes redondos. Y eso es realmente cuando usamos cada característica que la biblioteca tiene para ofrecer. Pero este no es el punto de partida típico. Así que generalmente podemos llegar bastante lejos con solo exportar un cliente de consulta, el proveedor, y probablemente usar consulta y usar mutación. Y si hacemos eso, si lo reducimos, esto nos lleva a menos de 10 kilobytes. Eso es 9.63.

4. Bundle Size and Declarative Data Fetching

Short description:

El tamaño del paquete de RackQuery puede no parecer ligero al principio, pero la biblioteca ahorra código al eliminar la necesidad de soluciones personalizadas. Con el enfoque declarativo de RackQuery, la obtención de datos al hacer clic en botones se puede lograr utilizando la clave de consulta y almacenando los filtros aplicados. El mecanismo de almacenamiento en caché de RackQuery asegura cachés separadas para cada clave, evitando la duplicación de datos.

Así que no me malinterpreten. Creo que el tamaño del paquete es algo importante a considerar antes de agregar una dependencia. Pero el debate sobre lo que es ligero y lo que no lo es no es realmente el más importante cuando se trata de una pieza tan central, como tu administrador de estado envejecido, especialmente porque hay una métrica que fácilmente se pasa por alto, y es el tamaño del paquete que ahorras por el código que no tienes que escribir. Creo que una biblioteca como RackQuery realmente se paga sola, porque cuanto más la usas, más te ahorra código que no tienes que escribir tú mismo.

Así que al verificar el tamaño del paquete de una biblioteca, es importante no pensar en el tamaño que agrega inmediatamente, sino también en lo que puede ahorrarte a largo plazo. Y en esa escala, creo que RackQuery es una clara ganancia, porque la mayoría de las soluciones personalizadas probablemente serían más grandes, o podrían fallar en algunos casos extremos, porque, sí, el almacenamiento en caché y la validación del caché son realmente difíciles.

Bien, el siguiente mito que quiero analizar es el hecho de que con RackQuery ni siquiera puedes obtener datos al hacer clic en un botón. Y escucho eso mucho, y el argumento es que es difícil para RackQuery hacer obtención de datos imperativa. Y es cierto porque RackQuery es declarativo por defecto. Lo que hacemos es escribir el hook use query, y le pasamos una clave de consulta y una función de consulta, y se ejecuta automáticamente para nosotros. Ahora este código intentaría leer la consulta del caché, y si no existen, irá y los obtendrá por nosotros. Hasta ahora, eso se ve bien, pero ahora intentemos agregar algo de filtrado a nuestra lista de tareas.

Cuando agregamos un formulario de filtro, ejecutamos un callback de aplicación, y cuando se llama, queremos volver a obtener eso con esos nuevos filtros. Así que si exploramos lo que devuelve use query por nuestra cuenta, podríamos encontrar la función refetch, y podríamos querer simplemente pasar una función refetch a ella. Creo que esto parece razonable, pero excepto que refetch no toma ningún argumento, así que esto simplemente no funciona. Y entiendo la frustración por esto, pero simplemente no es como RackQuery fue diseñado para funcionar. Porque mira, si tenemos una clave codificada como tasks, y volvemos a obtener eso con diferentes argumentos, no solo sobrescribiríamos los datos que habíamos almacenado en caché para esos otros filtros, también correríamos en condiciones de carrera con ese efecto.

Así que RackQuery ha resuelto ambos problemas con el enfoque declarativo al poner todas nuestras dependencias, y eso es todo lo que usamos dentro de la función de consulta, en la clave de consulta. Y eso significa que tenemos que almacenar nuestro filtro aplicado en algún lugar, y en este ejemplo simplemente los he puesto en el estado de React. Ahora cuando esos filtros aplicados cambian, la clave cambia y RackQuery verá una nueva clave de consulta y luego obtendrá Y este enfoque nos llevará del pensamiento imperativo, como si hago clic en ese botón, quiero hacer alguna obtención, hacia la forma declarativa de quiero datos que coincidan con este estado, y cómo cambia es realmente irrelevante. Y también es relevante dónde almacenamos esos filtros aplicados.

He usado useState antes, pero en realidad es un cambio bastante directo hacer una navegación con diferentes parámetros de búsqueda si usamos algo como 10StackRouter. Esto es, por supuesto, seguro en cuanto a tipos, dependiendo del esquema de parámetros de búsqueda que hayamos definido en nuestra ruta. Y ahora obtenemos un montón de cosas gratis, como por ejemplo URLs compartibles o navegación con el botón de retroceso del navegador, lo cual creo que es realmente genial. Otra cosa genial es que si cambiamos los filtros de nuevo a algo que ya hemos buscado, como dije antes, obtenemos un resultado instantáneo. Y eso es porque RackQuery almacena todo por separado por la clave. En ese sentido es un caché de documentos simple donde las respuestas completas se almacenarán para cualquier clave dada. Así que sí, en este ejemplo esto también significa que si una tarea está tanto en estado abierto como en prioridad alta, estará en ambos cachés. Porque no hay almacenamiento en caché normalizado en RackQuery. En un caché normalizado, cada pieza de datos se almacena solo una vez, y otras partes solo la referencian para evitar esa duplicación de datos.

5. Normalized Caching and Learning Curve

Short description:

RackQuery no soporta almacenamiento en caché normalizado, pero para la mayoría de las aplicaciones, volver a obtener datos después de la invalidación funciona bien. Si necesitas almacenamiento en caché normalizado, puedes revisar Normie. Aunque RackQuery tiene una curva de aprendizaje, comenzar con una sola consulta puede proporcionar el 80% de su propuesta de valor. Aprende gradualmente el resto de la API según sea necesario. La API de consulta ofrece almacenamiento en caché, duplicación de solicitudes, stale-while-revalidate, actualizaciones en segundo plano, gestión de estado global, reintentos y más. A medida que la complejidad de la aplicación crece, RackQuery ofrece características más profundas como actualizaciones optimistas y consultas infinitas. El sistema de complementos y las suscripciones de caché de bajo nivel proporcionan flexibilidad. No es necesario aprender todo desde el principio.

Hay soluciones dedicadas para GraphQL, por ejemplo, como Apollo Client o Urql, y ofrecen almacenamiento en caché normalizado porque son conscientes del esquema y las relaciones entre entidades. Pero RackQuery en este sentido no sabe nada, no sabe qué hay en el caché, solo conoce la promesa que se devuelve. Ahora tenemos una larga lista de comparaciones de características en nuestra documentación y el almacenamiento en caché normalizado es prácticamente lo único que no soportamos. Es un problema bastante difícil de resolver y también puede añadir mucha complejidad a tu lógica de caché. Así que la compensación que hemos tomado es no soportarlo. También creo que para la mayoría de las aplicaciones simplemente volver a obtener datos después de una invalidación probablemente funcione bien y también es más fácil de razonar. Así que sí, si estás usando GraphQL y necesitas almacenamiento en caché normalizado, RackQuery podría no ser la mejor opción para ti. Sin embargo, hay una solución comunitaria que quiero destacar que se llama Normie. Intenta traer normalización automática y actualizaciones de datos a las bibliotecas de obtención de datos y tiene integraciones para RackQuery, SWR y RTKQuery. Así que podrías querer echarle un vistazo si eso te parece interesante.

Así que no hacemos almacenamiento en caché normalizado porque queremos mantener las cosas simples pero aún así una cosa que escucho mucho es que RackQuery es complicado y tiene una curva de aprendizaje pronunciada. Ahora creo que si algo es fácil de entender eso siempre es subjetivo. Podría haber algo fácil de entender para ti que es un misterio total para mí. Pero creo que es innegable que RackQuery, como cualquier concepto que vale la pena aplicar, tiene una curva de aprendizaje y también tiene una superficie de API que no es la más pequeña. Fui mucho a los detalles del diseño de la API de RackQuery en mi última charla en la React Advanced Conference a principios de este año. Así que si quieres una mirada en profundidad a eso, por favor échale un vistazo. Pero solo para tocar el tema creo que Tana tiene un gran tweet que resume los objetivos de diseño de RackQuery donde dice que la API de consulta es en realidad de tamaño medio cuando la desglosas toda pero la parte más importante es que puedes entender y aprender cómo usarla comenzando con una sola consulta que proporciona el 80% de toda la propuesta de valor en el primer intento. A partir de ahí, el resto de su API se puede aprender gradualmente si es necesario. Así que aunque la API de consulta podría parecer abrumadora al principio, no necesitamos aprender todo de una vez. Podemos comenzar solo con useQuery con las opciones mínimas requeridas que son la clave de consulta y la función de consulta. Y ya obtenemos un montón de cosas solo usando este código simple. Obtenemos almacenamiento en caché y duplicación de solicitudes, hay stale while revalidate, actualizaciones en segundo plano, gestión de estado global, reintentos, como la lista sigue y sigue. Y luego más tarde podríamos añadir una mutación para hacer algunas actualizaciones y luego vincular eso de nuevo a la consulta con invalidación de consulta. Ahora eso ya es un poco más de código pero con esos dos podemos llegar muy lejos en nuestra aplicación. Y una vez que la complejidad de nuestra aplicación crezca, podríamos querer mirar algunas cosas más profundas que RackQuery tiene para ofrecer. Tal vez queramos añadir una actualización optimista aquí y allá en uno de nuestros lugares o tal vez necesitemos una consulta infinita a veces. Ahora esos son un poco más complicados y luego todo el camino en esta escala poderosa y flexible tenemos nuestro sistema de complementos y nuestras suscripciones de caché de muy bajo nivel que estamos usando por ejemplo para construir nuestras DevTools. Ahora esos son realmente poderosos y flexibles pero una vez que alcanzas una cierta complejidad de aplicación, podrías estar realmente feliz de que esos existan también. Pero creo que la API de consulta está absolutamente diseñada para evolucionar contigo. Así que sí, no creas que es necesario aprender todo desde el principio, si eso se siente abrumador.

6. Managing Synchronous State and Built-in Solutions

Short description:

ReqQuery no es adecuado para gestionar el estado sincrónico. Usa la herramienta adecuada para el trabajo, como Zustand o XStateStore, para gestionar el estado del cliente. Hay mejores opciones que usar ReqQuery para todo. El equipo de React prioriza obtener la API correcta antes de lanzar soluciones integradas para tareas básicas como la obtención de datos.

Sí, hay mucho que aprender pero definitivamente podemos llegar allí de manera incremental. Bien. Así que una vez que hemos aprendido la API y pensamos que es realmente genial, queremos empezar a gestionar todo el estado con ella, ¿verdad? Pero como ReqQuery es malo, realmente no quiere que hagamos eso. Está realmente diseñado para trabajar solo con estado asincrónico porque es un gestor de estado asincrónico que conoce las necesidades del estado del servicio que tenemos y es un buen gestor de estado del servicio que conoce las necesidades del estado del servicio que estamos almacenando en caché. Sabe que los datos que estamos viendo son solo una instantánea de la fuente de verdad del momento en que los obtuvimos y que la fuente de verdad real vive en el servidor. Así que lo que intenta hacer es intentar revalidar y mantener nuestros datos actualizados porque también es una herramienta de sincronización de datos. Y podría incluso hacer algunas suposiciones sobre nuestra conexión de red cuando obtiene ese estado y podría incluso intentar obtener ese estado de nuevo. Estas son todas cosas que amamos de ReqQuery pero no es algo que necesitemos cuando queremos gestionar algún estado sincrónico como por ejemplo un toggle de barra lateral. Si yo escribiera ese código en ReqQuery probablemente se vería así pero no hagas esto. Está lejos de ser ideal. Necesitamos hacer un montón de cosas aquí. Necesitamos idear una clave única como el estado de la barra lateral que no colisione con nada más que tengamos en nuestra aplicación. Ni siquiera tenemos una función de consulta aquí porque no hay nada asincrónico que hacer. Solo pasamos datos con datos iniciales sincrónicamente y luego los actualizamos con set query data. Y por último, necesitamos desactivar un montón de opciones de configuración para realmente detener a ReqQuery de intentar lo que quiere hacer por defecto, que es gestionar y sincronizar ese estado asincrónico. Así que creo que hacer algo como esto no es fácil de hacer bien. También es un poco verboso y tampoco es muy eficiente. Así que la división en estados de cliente y servicio que tenemos es realmente a propósito porque tienen diferentes necesidades. Así que realmente usaría la herramienta adecuada para el trabajo adecuado. Y hay muchas otras soluciones para gestionar el estado del cliente. Por ejemplo, una que me gusta es Zustand porque es mínima, eficiente y no tiene opiniones. Todo lo que tenemos que hacer aquí es definir una tienda con nuestro estado y luego las acciones para actualizarlo. Y luego he creado un hook personalizado solo para mantener la misma interfaz que tenía en la implementación anterior. Y algo similar que también me gusta bastante es XStateStore que se ve bastante similar pero funciona un poco mejor en TypeScript porque los tipos se infieren y también es impulsado por eventos. Pero la cuestión aquí es que no hay sorpresas con ninguno de los dos. Ambos son perfectamente capaces de gestionar ese estado del cliente para nosotros. Así que creo que definitivamente hay mejores opciones que solo usar ReqQuery para todo. Así que el último punto que tengo es un punto extra. Creo que es un poco gracioso que a veces escucho la pregunta como por qué siquiera necesitamos una biblioteca de terceros para hacer algo tan básico como la obtención de datos en React? ¿Por qué esto no está simplemente integrado en React? Y realmente no puedo responder eso porque no trabajo en React pero ciertamente entiendo la frustración de que no tengamos algo una primitiva de agente integrada en React como hay, por ejemplo, un create resource en SolidJS. Pero creo que la razón de eso podría ser que el equipo de React realmente intenta obtener una API correcta antes de realmente lanzarla.

7. React's Vision and Overwhelming Docs

Short description:

React carece de selectores de contexto y tiene una visión diferente para gestionar la renderización con use-memo. La arquitectura de suspense de React desacopla los componentes de los estados de carga y error y funciona bien con TypeScript. Los componentes de servidor y suspense son las primitivas asincrónicas que hemos estado esperando. Usa query si tu framework no soporta componentes de servidor. Gracias por tu trabajo y el amor de la comunidad. Algunos encuentran la documentación abrumadora, especialmente para juniors y novatos.

Y como ejemplo, a menudo me he preguntado, o creo que muchos de nosotros a menudo nos hemos preguntado, por qué no tenemos selectores de contexto en React. Eso es algo que mucha gente ha estado solicitando para obtener esas suscripciones de grano fino a un contexto de React. Creo que es la razón por la que todas esas otras bibliotecas de gestión de estado incluso existen es que esto no existe. Tendríamos un contexto de configuración con un montón de configuraciones probablemente y luego un tema encima de eso y use-theme solo se suscribiría a ese tema. Y luego encima de eso, tendríamos use-color, que solo volvería a renderizar el componente que lo usa cuando ese color específico cambie. Ahora, esto no existe y creo que probablemente no es porque sería demasiado difícil de implementar sino porque el equipo de React tiene una visión diferente. Es que creamos un nuevo operador use dentro de use-memo y luego React se detendrá de renderizar si devolvemos el mismo valor. Ahora, creo que esto ya compone mucho mejor que los selectores y eventualmente, podría llevar a un lugar donde podamos simplemente escribir el mismo código sin use-memo en absoluto gracias al compilador de React. Ahora, creo que esa es una gran visión pero lleva tiempo llegar allí, así que esto no es sintaxis real, no existe. Y por supuesto, con la obtención de datos, fue una historia similar porque todos solo querían tener use-query pero el equipo de React simplemente piensa en grande. Creo que suspense es una arquitectura hermosa donde tus componentes se desacoplan de manejar estados de carga y error y también funciona realmente, realmente bien con TypeScript porque en este caso, los datos nunca pueden ser indefinidos. Y por supuesto, la visión de React va más allá de la obtención de datos del lado del cliente ahora que tenemos componentes de servidor asincrónicos. Realmente desearía tener una cita del equipo de React pero no pude encontrar una buena así que solo voy a decirlo yo mismo que suspense y los componentes de servidor son la primitiva asincrónica que hemos estado esperando. Y sí, si estás trabajando con un framework que soporta componentes de servidor entonces por favor úsalos y hasta entonces, siéntete libre de usar query. Gracias. Así que gracias por la charla y hay mucho amor de hecho en la comunidad como mencionaste. Solo quiero leer uno. Hay un comentario aquí. Usamos 10-sec query. Estoy súper feliz con ello. Y si no lo haces, solo lee la documentación y pruébalo. Así que gracias por tu trabajo. Pero luego está este más jugoso porque esencialmente esta persona, no quiero poner palabras en su boca pero esto es como RTFM, lee el manual tipo de comentario. O mi blog. O tu blog. Pero hay otra pregunta aquí y ahí está. ¿Por qué son tan abrumadores los documentos de 10-sec? Creo que para los juniors y novatos pueden ser muy abrumadores. Ahora, por supuesto, es un equilibrio difícil de lograr pero ¿tienes alguna idea sobre cómo lo estás haciendo y dónde está eso ahora mismo? Sí, ese es un buen punto. Probablemente debería haber incluido eso tal vez en la charla. Creo que los documentos probablemente necesitan una renovación.

8. Improving Documentation Structure

Short description:

La estructura de la documentación podría estar más estructurada y llevarte de cero al final en un solo flujo. Considera revisar un curso si estás teniendo dificultades con la documentación.

La estructura de la documentación ha estado allí desde siempre donde básicamente tenemos como guías que creo que es una buena idea comenzar con guías y luego básicamente la definición de la API y lo que tienes y luego los ejemplos que tenemos. Pero creo que las guías podrían estar un poco más estructuradas y deberían llevarte de cero al final en un solo flujo. No quiero hacer publicidad pero tengo un curso donde hago exactamente eso. Así que sí, también puedes obtener eso si quieres. Creo que es bueno publicitar cosas que realmente ayudan a las personas. Si estás teniendo dificultades con la documentación, entonces tal vez sea una buena cosa para revisar.

9. Using TensorStack Query with Next.js

Short description:

TensorStack Query puede ser una buena opción para aplicaciones de enrutador de aplicaciones Next.js, dependiendo del caso de uso. Proporciona integración con componentes del servidor y Next.js, permitiendo la obtención de datos en el servidor y el almacenamiento en caché automático. Sin embargo, no es necesario usar TensorStack Query si ya estás utilizando un marco maduro con componentes del servidor y acciones integradas. Los nombres React query y TensorStack query se usan indistintamente, pero React query fue renombrado como TensorStack query en la versión 4, con paquetes separados para diferentes marcos.

Bueno, bien vamos a seguir el orden democrático y ver las preguntas más votadas. Entonces, ¿es TensorStack Query una buena opción para aplicaciones de enrutador de aplicaciones Next.js? Entonces creo que esto está implicando todas las acciones del servidor y lo que sea. Tengo una publicación en el blog sobre ese tema. Se llama You Might Not Need React Query. Y aún así, como dije si estás usando un marco maduro que tiene componentes del servidor y acciones integradas y esto es suficiente para tu caso de uso entonces no traería TensorQuery desde el principio solo porque así es como siempre lo hemos hecho. Solo evalúa la situación.

Todavía hay muchas situaciones donde no tienes una aplicación Greenfield y quieres moverte al enrutador de aplicaciones y ya lo tienes en su lugar, ¿verdad? Entonces es una buena manera de simplemente mantenerlo y migrar de manera incremental. Pero también probablemente hay algunos casos de uso altamente interactivos donde un refetch o una revalidación solo en una navegación de ruta no es suficiente. Así que querrías que las actualizaciones sucedan más frecuentemente con todas las actualizaciones automáticas que tenemos. O tal vez tienes una consulta infinita con desplazamiento infinito, lo cual creo que todavía es bastante difícil de lograr solo con componentes del servidor. Así que solo depende del caso de uso. Definitivamente intentamos traer una buena integración con componentes del servidor y también con Next.js en sí, donde puedes iniciar la obtención de datos en el servidor y luego transmitir la promesa al cliente donde el caché luego realmente lo recogerá. Intentamos hacer esto también más automáticamente. Esta es una fase un poco experimental en la que estamos ahora. Pero sí, creo que puedes usarlo. No creo que tengas que usarlo.

Sí, es realmente interesante. Así que en realidad te entrevisté en el escenario avanzado de React hace solo un par de meses y tú mencionaste esa API y me di cuenta de que nosotros no la estábamos usando en el trabajo, así que la puse después. Así que aprendes algo cuando vienes a estas cosas. Una cosa que noté es que tú como que intercambias en el título de la charla y ahora tú hablas, usas React query y 10 stack query los nombres, y creo que podría haber algo de confusión al respecto. Entonces, ¿qué está pasando con eso? Solía ser React query hasta la versión 3. Hay un paquete DMPM React query que todavía recibe muchas descargas. Así que para obtener la descarga para realmente combinar esos dos, hice eso con Chatchpg por cierto, para simplemente combinar los números de estadísticas. Y luego decidimos que en realidad teníamos un núcleo agnóstico, como el núcleo es solo en JavaScript y React es un adaptador separado encima de eso. Y la gente comenzó a hacer un adaptador de vista y un adaptador svelte por su cuenta, pero solo dependiendo de React query y luego obtendrías un marco diferente encima de eso. Así que decidimos hacer todo el cambio de marca con la versión 4 y estamos publicando cada paquete por separado. Hay un paquete de núcleo de 10 stack query que es solo TypeScript puro. Hay 10 stack solid query, hay 10 stack view query y luego también hay 10 stack React query, el paquete. Así que el nombre completo sería 10 stack React query pero no creo que nadie realmente diga eso. Así que solo sigo llamándolo React query.

10. 10 Stack Query and Router

Short description:

El concepto de 10 stack query se discute, junto con el 10 stack router. El orador está manteniendo el router y destaca sus conceptos únicos, como tratar los parámetros de búsqueda como un gestor de estado y tener seguridad de tipos e integración de suspense en todas las rutas.

Y si estamos hablando del concepto en sí, entonces probablemente sea 10 stack query. Si construyes aplicaciones, ¿eres como un maximalista de 10 stack? ¿Usas el 10 stack router, por ejemplo? ¿O es la biblioteca de consultas más tu interés principal? Así que el router es un proyecto realmente genial. En la última aplicación que hemos construido desde cero, también elegimos el router. También estoy manteniendo el router ahora, así que una divulgación completa. Sí, así que creo que algunos de los conceptos en el router son realmente únicos, como cómo los parámetros de búsqueda se tratan como un gestor de estado, cómo tienes la seguridad de tipos que fluye por todas partes, cómo tienes integración de suspense en todas las rutas. Podría ser una buena charla también. Sí, supongo que te veré en el panel de mantenedores de desarrolladores y luego te veré en el panel de no quemarse después. Oh sí, pensé que era el mismo panel, como tiene que ser el mismo. No, son dos diferentes... uno es para personas que ya han reconocido que tienen un problema y las personas que todavía están caminando en el problema. Bien, así que vamos de nuevo, en un orden democrático.

11. Combining React Query with HTTP Caching

Short description:

Combinar React Query con almacenamiento en caché HTTP usando encabezados de control de caché permite un tipo diferente de capa de almacenamiento en caché. Al establecer el tiempo de obsolescencia en cero, las solicitudes de obtención activadas por React Query pueden ser capturadas por el caché del navegador, habilitando la funcionalidad sin conexión. Esta combinación proporciona una solución de almacenamiento en caché robusta.

¿Existen patrones recomendados para combinar React Query con almacenamiento en caché HTTP para APIs REST usando, por ejemplo, encabezados de control de caché? Definitivamente puedes hacer eso y es un tipo diferente de capa de almacenamiento en caché. Tenemos como esta configuración de tiempo de obsolescencia que básicamente define cuándo los datos se vuelven obsoletos y se siente como que los encabezados de control de caché hacen algo similar pero una de las cosas buenas es que si estás usando encabezados de control de caché simplemente mantendría el tiempo de obsolescencia en cero porque incluso si una obtención se activa con demasiada frecuencia desde React Query aún sería capturada por el caché del navegador y sería entregada desde ese caché directamente. Así que en este punto puedes mantener los valores predeterminados y realmente no importa y en realidad es bueno usar el caché del navegador para eso también porque esas solicitudes de obtención también funcionarían mientras estás sin conexión. Así que una vez que tienes eso almacenado en el caché del navegador incluso si no lo tienes en nuestro caché en memoria esas solicitudes aún funcionarían. Así que sí, una combinación de esos es definitivamente algo que puedes hacer.

Check out more articles and videos

We constantly think of articles and videos that might spark Git people interest / skill us up or help building a stellar career

Una Guía del Comportamiento de Renderizado de React
React Advanced 2022React Advanced 2022
25 min
Una Guía del Comportamiento de Renderizado de React
Top Content
This transcription provides a brief guide to React rendering behavior. It explains the process of rendering, comparing new and old elements, and the importance of pure rendering without side effects. It also covers topics such as batching and double rendering, optimizing rendering and using context and Redux in React. Overall, it offers valuable insights for developers looking to understand and optimize React rendering.
Construyendo Mejores Sitios Web con Remix
React Summit Remote Edition 2021React Summit Remote Edition 2021
33 min
Construyendo Mejores Sitios Web con Remix
Top Content
Remix is a web framework built on React Router that focuses on web fundamentals, accessibility, performance, and flexibility. It delivers real HTML and SEO benefits, and allows for automatic updating of meta tags and styles. It provides features like login functionality, session management, and error handling. Remix is a server-rendered framework that can enhance sites with JavaScript but doesn't require it for basic functionality. It aims to create quality HTML-driven documents and is flexible for use with different web technologies and stacks.
Compilador React Forget - Entendiendo React Idiomático
React Advanced 2023React Advanced 2023
33 min
Compilador React Forget - Entendiendo React Idiomático
Top Content
Joe Savona
Mofei Zhang
2 authors
The Talk discusses React Forget, a compiler built at Meta that aims to optimize client-side React development. It explores the use of memoization to improve performance and the vision of Forget to automatically determine dependencies at build time. Forget is named with an F-word pun and has the potential to optimize server builds and enable dead code elimination. The team plans to make Forget open-source and is focused on ensuring its quality before release.
Uso efectivo de useEffect
React Advanced 2022React Advanced 2022
30 min
Uso efectivo de useEffect
Top Content
Today's Talk explores the use of the useEffect hook in React development, covering topics such as fetching data, handling race conditions and cleanup, and optimizing performance. It also discusses the correct use of useEffect in React 18, the distinction between Activity Effects and Action Effects, and the potential misuse of useEffect. The Talk highlights the benefits of using useQuery or SWR for data fetching, the problems with using useEffect for initializing global singletons, and the use of state machines for handling effects. The speaker also recommends exploring the beta React docs and using tools like the stately.ai editor for visualizing state machines.
React Query API Design – Lecciones Aprendidas
React Advanced 2024React Advanced 2024
26 min
React Query API Design – Lecciones Aprendidas
Top Content
I'm super excited to be here today, giving my first live talk at an in-person conference. Dominik, the maintainer of React Query, walks through the API design decisions, including success stories, trade-offs, and mistakes. Tener Linsley designed React Query's medium-sized query API to be minimal, intuitive, powerful, and flexible. Major versions in open source require marketing efforts, but not primarily for adding new features. TypeScript is crucial for building projects and managing user demands in open source can be challenging. The addition of the max pages option improved performance and avoided unnecessary refetches. Inversion of control gives users flexibility, but mistakes can happen in API design. Open source requires time management and feedback from users. API design is influenced by typing ease and good TypeScript support. Getting involved in open source involves trial and error and joining community platforms like TanStack Discord. Dominik's journey started during the pandemic and he can be found on Twitter, TanStack Discord, and his blog.
Enrutamiento en React 18 y más allá
React Summit 2022React Summit 2022
20 min
Enrutamiento en React 18 y más allá
Top Content
Routing in React 18 brings a native app-like user experience and allows applications to transition between different environments. React Router and Next.js have different approaches to routing, with React Router using component-based routing and Next.js using file system-based routing. React server components provide the primitives to address the disadvantages of multipage applications while maintaining the same user experience. Improving navigation and routing in React involves including loading UI, pre-rendering parts of the screen, and using server components for more performant experiences. Next.js and Remix are moving towards a converging solution by combining component-based routing with file system routing.

Workshops on related topic

Masterclass de Depuración de Rendimiento de React
React Summit 2023React Summit 2023
170 min
Masterclass de Depuración de Rendimiento de React
Top Content
Featured Workshop
Ivan Akulov
Ivan Akulov
Los primeros intentos de Ivan en la depuración de rendimiento fueron caóticos. Vería una interacción lenta, intentaría una optimización aleatoria, vería que no ayudaba, y seguiría intentando otras optimizaciones hasta que encontraba la correcta (o se rendía).
En aquel entonces, Ivan no sabía cómo usar bien las herramientas de rendimiento. Haría una grabación en Chrome DevTools o React Profiler, la examinaría, intentaría hacer clic en cosas aleatorias, y luego la cerraría frustrado unos minutos después. Ahora, Ivan sabe exactamente dónde y qué buscar. Y en esta masterclass, Ivan te enseñará eso también.
Así es como va a funcionar. Tomaremos una aplicación lenta → la depuraremos (usando herramientas como Chrome DevTools, React Profiler, y why-did-you-render) → identificaremos el cuello de botella → y luego repetiremos, varias veces más. No hablaremos de las soluciones (en el 90% de los casos, es simplemente el viejo y regular useMemo() o memo()). Pero hablaremos de todo lo que viene antes - y aprenderemos a analizar cualquier problema de rendimiento de React, paso a paso.
(Nota: Esta masterclass es más adecuada para ingenieros que ya están familiarizados con cómo funcionan useMemo() y memo() - pero quieren mejorar en el uso de las herramientas de rendimiento alrededor de React. Además, estaremos cubriendo el rendimiento de la interacción, no la velocidad de carga, por lo que no escucharás una palabra sobre Lighthouse 🤐)
Next.js para Desarrolladores de React.js
React Day Berlin 2023React Day Berlin 2023
157 min
Next.js para Desarrolladores de React.js
Top Content
Featured WorkshopFree
Adrian Hajdin
Adrian Hajdin
En esta avanzada masterclass de Next.js, profundizaremos en conceptos clave y técnicas que permiten a los desarrolladores de React.js aprovechar al máximo Next.js. Exploraremos temas avanzados y prácticas prácticas, equipándote con las habilidades necesarias para construir aplicaciones web de alto rendimiento y tomar decisiones arquitectónicas informadas.
Al final de esta masterclass, serás capaz de:1. Comprender los beneficios de los Componentes del Servidor React y su papel en la construcción de aplicaciones React interactivas, renderizadas por el servidor.2. Diferenciar entre el tiempo de ejecución de Edge y Node.js en Next.js y saber cuándo usar cada uno en función de los requisitos de tu proyecto.3. Explorar técnicas avanzadas de Renderizado del Lado del Servidor (SSR), incluyendo streaming, fetching paralelo vs. secuencial, y sincronización de datos.4. Implementar estrategias de caché para mejorar el rendimiento y reducir la carga del servidor en las aplicaciones Next.js.5. Utilizar Acciones React para manejar la mutación compleja del servidor.6. Optimizar tus aplicaciones Next.js para SEO, compartir en redes sociales, y rendimiento general para mejorar la descubrabilidad y la participación del usuario.
Aventuras de Renderizado Concurrente en React 18
React Advanced 2021React Advanced 2021
132 min
Aventuras de Renderizado Concurrente en React 18
Top Content
Featured Workshop
Maurice de Beijer
Maurice de Beijer
Con el lanzamiento de React 18 finalmente obtenemos el tan esperado renderizado concurrente. Pero, ¿cómo va a afectar eso a tu aplicación? ¿Cuáles son los beneficios del renderizado concurrente en React? ¿Qué necesitas hacer para cambiar al renderizado concurrente cuando actualices a React 18? ¿Y qué pasa si no quieres o no puedes usar el renderizado concurrente todavía?

¡Hay algunos cambios de comportamiento de los que debes estar al tanto! En esta masterclass cubriremos todos esos temas y más.

Acompáñame con tu portátil en esta masterclass interactiva. Verás lo fácil que es cambiar al renderizado concurrente en tu aplicación React. Aprenderás todo sobre el renderizado concurrente, SuspenseList, la API startTransition y más.
Consejos sobre React Hooks que solo los profesionales conocen
React Summit Remote Edition 2021React Summit Remote Edition 2021
177 min
Consejos sobre React Hooks que solo los profesionales conocen
Top Content
Featured Workshop
Maurice de Beijer
Maurice de Beijer
La adición de la API de hooks a React fue un cambio bastante importante. Antes de los hooks, la mayoría de los componentos tenían que ser basados en clases. Ahora, con los hooks, estos son a menudo componentes funcionales mucho más simples. Los hooks pueden ser realmente simples de usar. Casi engañosamente simples. Porque todavía hay muchas formas en las que puedes equivocarte con los hooks. Y a menudo resulta que hay muchas formas en las que puedes mejorar tus componentes con una mejor comprensión de cómo se puede usar cada hook de React.Aprenderás todo sobre los pros y los contras de los diversos hooks. Aprenderás cuándo usar useState() versus useReducer(). Veremos cómo usar useContext() de manera eficiente. Verás cuándo usar useLayoutEffect() y cuándo useEffect() es mejor.
Presentando FlashList: Construyamos juntos una lista performante en React Native
React Advanced 2022React Advanced 2022
81 min
Presentando FlashList: Construyamos juntos una lista performante en React Native
Top Content
Featured Workshop
David Cortés Fulla
Marek Fořt
Talha Naqvi
3 authors
En esta masterclass aprenderás por qué creamos FlashList en Shopify y cómo puedes usarlo en tu código hoy. Te mostraremos cómo tomar una lista que no es performante en FlatList y hacerla performante usando FlashList con mínimo esfuerzo. Usaremos herramientas como Flipper, nuestro propio código de benchmarking, y te enseñaremos cómo la API de FlashList puede cubrir casos de uso más complejos y aún así mantener un rendimiento de primera categoría.Sabrás:- Breve presentación sobre qué es FlashList, por qué lo construimos, etc.- Migrando de FlatList a FlashList- Enseñando cómo escribir una lista performante- Utilizando las herramientas proporcionadas por la biblioteca FlashList (principalmente el hook useBenchmark)- Usando los plugins de Flipper (gráfico de llamas, nuestro perfilador de listas, perfilador de UI & JS FPS, etc.)- Optimizando el rendimiento de FlashList utilizando props más avanzados como `getType`- 5-6 tareas de muestra donde descubriremos y solucionaremos problemas juntos- Preguntas y respuestas con el equipo de Shopify
React, TypeScript y TDD
React Advanced 2021React Advanced 2021
174 min
React, TypeScript y TDD
Top Content
Featured Workshop
Paul Everitt
Paul Everitt
ReactJS es extremadamente popular y, por lo tanto, ampliamente soportado. TypeScript está ganando popularidad y, por lo tanto, cada vez más soportado.

¿Los dos juntos? No tanto. Dado que ambos cambian rápidamente, es difícil encontrar materiales de aprendizaje precisos.

¿React+TypeScript, con los IDEs de JetBrains? Esa combinación de tres partes es el tema de esta serie. Mostraremos un poco sobre mucho. Es decir, los pasos clave para ser productivo, en el IDE, para proyectos de React utilizando TypeScript. En el camino, mostraremos el desarrollo guiado por pruebas y enfatizaremos consejos y trucos en el IDE.