Por qué deberías usar Redux en 2024

Muy bien. Buenos días. Mi nombre es Mark Erickson, y hoy estoy muy emocionado de hablar sobre por qué deberías usar Redux hoy.

Un par de cosas rápidas sobre mí. Soy un ingeniero senior de front-end en Replay donde estamos construyendo un depurador de viaje en el tiempo para aplicaciones JavaScript. Si no lo has visto, por favor échale un vistazo. Te ahorrará mucho tiempo investigando problemas e intentando arreglar tus pruebas inestables. Ven y pregúntame sobre ello más tarde. Estoy muy contento de mostrarlo. Soy un respondedor de preguntas. Responderé preguntas prácticamente en cualquier lugar donde haya un cuadro de texto en internet. Recojo cualquier tipo de enlace que parezca incluso remotamente útil. Escribo publicaciones de blog extremadamente largas, y soy un mantenedor de Redux. He hecho la mayor parte de nuestra documentación, y creé Redux Toolkit, pero la mayoría de la gente me conoce como ese tipo con el avatar de los Simpsons. Se ha convertido en una marca registrada.

¿Por qué estamos teniendo esta charla de todos modos? Bueno, históricamente, el equipo de Redux en realidad no ha dedicado realmente ningún tiempo en absoluto tratando de animar a la gente a usar Redux. De hecho, si acaso, hemos pasado la mayor parte de nuestro tiempo diciendo a la gente que no deberías realmente usar Redux en esta situación, y parte de eso es porque Redux ha sido usado en muchos lugares donde realmente no debería haberlo sido. Así que nuestro objetivo como mantenedores no es como si estuviéramos tratando de ganar cuota de mercado. Solo queremos que Redux sea una herramienta muy buena para que si eliges usarla, funcione bien para ti. Pero todavía vemos muchas preguntas sobre cuándo tiene sentido usar Redux? Ahora, preguntas rápidas por curiosidad.

¿Cuántos de ustedes han usado Redux en alguna forma en absoluto? Vale. Básicamente toda la sala. Genial. ¿Cuántos de ustedes han usado el moderno paquete Toolkit de Redux? Vale. Algo menos de manos. Eso es preocupante. Y solo por curiosidad, ¿cuántas personas aquí nunca han usado Redux? Vale, como, diez personas. De acuerdo.

Entonces, ¿qué estoy tratando de hacer hoy? Soy un gran creyente en entender la historia de las herramientas, por qué fueron creadas y qué problemas estaban tratando de resolver. Así que vamos a echar un vistazo rápido a la historia de Redux y las circunstancias que rodean su creación. Vamos a hablar de cómo el ecosistema ha evolucionado con el tiempo. Hablaremos un poco sobre algunas de las compensaciones de usar Redux. Y voy a dar algunas razones positivas por las que vale la pena considerar el uso de Redux hoy. Ahora tenemos un tiempo limitado, el reloj ya está corriendo. No voy a intentar comparar Redux versus otras bibliotecas. Ni siquiera voy a hablar de, como, lo increíble que es el Toolkit de Redux. He dado charlas como esa antes. Puedes buscarlas en tu propio tiempo. Así que una rápida historia de Redux. React salió públicamente en 2013. Y un año después, Facebook anunció este concepto llamado la Arquitectura Flux. Y el problema era que tenían dificultades para mantener el estado sincronizado en diferentes partes de su aplicación. Más famosamente, el botón de notificaciones mostraba, como, diferentes valores que el resto de la UI. Y tenían problemas para poder entender cómo se actualizaban los datos. Así que se les ocurrió un patrón llamado la Arquitectura Flux, que usaba palabras como tiendas y despachadores y objetos de acción. Y estos podrían sonar familiares. Y eso es porque Redux en realidad obtuvo todos estos términos de Flux inicialmente. Es, como, la razón por la que se llaman acciones y no eventos es porque Flux usó ese nombre primero y simplemente mantuvimos el nombre de Flux. Ahora, Facebook no lanzó una biblioteca completa para Flux. Solo un par de utilidades.

Solo un par de utilidades. Y así la comunidad de React comenzó a producir docenas de diferentes bibliotecas inspiradas en Flux, cada una con nombres en su mayoría de broma basados en Regreso al Futuro. Me refiero a este período como las Guerras de Flux. Y así, en febrero de 2015, Dan Abramov publicó un blog llamado El Caso de Flux, donde habló sobre algunos de los beneficios de usar este patrón en las aplicaciones de React. Y se trataba principalmente de cosas como poder almacenar en caché los data o separar las actualizaciones de lo que sucedió y tener una única fuente de verdad. Ahora, lo que esto significa es que el contexto de la época, lo que la gente estaba tratando de resolver era la gestión del estado del lado del cliente y entender cómo se actualizaba el estado en tu aplicación. Así que a mediados de 2015, publicó otra entrada llamada La Evolución de los Marcos de Flux y comenzó a trabajar en Redux. Y si miras uno de los primeros archivos readme, algunos de los principios y objetivos que tenía para Redux eran cosas como que iba a usar la programación funcional, pero no deberías tener que ser un experto en programación funcional para usarlo. Todo debería ser recargable en caliente. Deberías poder suscribirte a piezas específicas de data que tus componentes necesitan. Debería tener la capacidad de usar herramientas de desarrollo para entender qué sucedió.

Y debería ser fácil extender la biblioteca para incorporar más funcionalidad. Un par de años después, escribí un par de publicaciones de blog que titulé El Tao de Redux. Y estaba tratando de expandir esto y explicar aún más cuáles eran los objetivos de Redux. Así que enumeré algunas cosas. Redux fue diseñado originalmente como otra biblioteca Flux. Ni siquiera estaba destinado a ser algo a gran escala. Es solo un ejemplo. Pero el gran objetivo es asegurarse de que sea fácil mantener el código que actualiza el estado. Como parte de eso, el historial de acciones despachadas debería tener significado. Deberías poder ver que el usuario hizo esto, el usuario hizo aquello, y leer a través del historial. Se pretende que tenga algunos principios de programación funcional. Debería llevarte a escribir más código que sea comprobable. Pero el flujo de datos y la lógica de actualización deberían ser muy explícitos. También hablé un poco sobre el diseño de la API. Lo diseñamos intencionalmente para que la lógica del reductor estuviera organizada por tu tipo de datos, los usuarios, las publicaciones, los comentarios. Las APIs de Redux en sí deberían ser bastante mínimas, pero la biblioteca en sí debería ser muy extensible. Así que estos eran los objetivos detrás de la creación de Redux.

Entonces, a mediados de 2015, Dan y Andrew comenzaron a colaborar en Redux. Dan lo anunció en React Europe, y un mes después, se publicó Redux 1.0. Fue un ciclo de desarrollo de dos meses. Redux se hizo popular de inmediato y, en un año, había eliminado todas las otras bibliotecas Flux, y la comunidad comenzó a asumir que si estás usando React, tienes que usar Redux. Tenga en cuenta que el equipo de React no dijo esto, y el equipo de Redux tampoco lo dijo. Esto fue como una cosa de la comunidad.

Así que las bibliotecas de Redux continuaron evolucionando. Lanzamos una versión 5 de React Redux en 2016, que mejoró el rendimiento, la versión 6 a finales de 2018, que utilizó el contexto moderno en su interior, pero al mismo tiempo, el ecosistema de React también estaba cambiando porque los hooks salieron en marzo de 2019, y todo el mundo estaba exigiendo que pusiéramos hooks en React Redux y en todas las demás bibliotecas en ese momento. Rediseñamos los internos de React Redux para usar hooks dentro de Connect poco después de eso, y luego publicamos nuestra propia API de hooks con use selector y dispatch en junio de 2019. Al mismo tiempo, había muchas quejas sobre cómo usar Redux. Me he cansado de escuchar la palabra boilerplate con el tiempo. Creamos Redux Toolkit para facilitar a las personas el uso de Redux. Lanzamos Redux Toolkit 1.0 en octubre de 19, y un año después, reescribí nuestros tutoriales para enseñar Redux Toolkit como el predeterminado.

En 2021, lanzamos la biblioteca de obtención de datos de consulta RTK, muy similar e inspirada por React query y SWR y Apollo. Un año después de eso, marqué el método original de create store como obsoleto. Todavía funciona bien. No rompí nada. Pero quería animar a la gente y hacer saber a muchas personas que existe RTK. Finalmente, el año pasado, pasé todo el año luchando con herramientas y paquetes de publicación y ESM y common.js y finalmente lancé RTK 2.0 y versiones mayores de todas nuestras otras bibliotecas para tener un mejor packaging y mejor compatibilidad con common.js, así como abandonar cosas como el soporte de IE11. Puedes ver que Redux en sí mismo ha evolucionado bastante con el tiempo.

Si volvemos atrás y pensamos por qué la gente incluso eligió Redux para empezar, puedo pensar en algunas razones diferentes. Una es que la API de contexto de React original estaba realmente rota. Podías pasar valores a través del árbol, pero no podías actualizar esos valores de manera consistente, por lo que mucha gente recurrió a otras bibliotecas para evitar eso. Redux fue la mejor implementación de la biblioteca Flux en su momento, en un momento en que la comunidad de React estaba de acuerdo en que Flux es la forma de gestionar el estado en las aplicaciones de React.

Podías recargar en caliente los componentes en ese momento, pero la forma en que funcionaba era limitada, y recargar un componente en realidad tiraría todo el estado del componente, y por lo tanto, para mantener el estado mientras estabas desarrollando, la gente a menudo usaba Redux sólo para mantener el estado en memoria. Y luego, por supuesto, estaban los líderes de pensamiento. De nuevo, no el equipo de React, no el equipo de Redux, sino ingenieros senior, gente de Twitter, lo que sea, que insistían en que, bueno, por supuesto, deberías estar usando Redux. También había algunas buenas razones arquitectónicas. React está diseñado con principios de programación funcional en mente, y también lo está Redux. El estado de React, está limitado a la forma de tu árbol de componentes. El estado se pasa como props a los hijos, y a veces diferentes partes del árbol de componentes necesitan acceder a los mismos data, y por lo tanto, tener una biblioteca externa de gestión de estado puede facilitar eso. Y finalmente, hay beneficios arquitectónicos al mover el estado fuera de la capa de UI, manteniendo la UI relativamente simple, y simplemente diciendo, aquí hay algo que sucedió, deje que las actualizaciones ocurran aquí.

Finalmente, previsibilidad y observability. Redux te proporciona un patrón de flujo de data muy consistente. Haces clic en la UI, se ejecuta el controlador, se despacha una acción, el reductor se actualiza, los selectores leen data, los componentes se vuelven a renderizar. Es un poco de trabajo, pero es un flujo muy consistente todo el tiempo. Los reductores y selectores de Redux son funciones puras. Son solo valores de entrada, argumentos de salida, lo que los hace muy fáciles de probar, y, por supuesto, las herramientas de desarrollo de Redux facilitan ver qué sucedió en la aplicación.

Entonces, ¿cuáles de estas razones siguen siendo relevantes hoy en día? Bueno, está bien, la mayoría de esas razones históricas están prácticamente muertas en este punto. Tenemos un contexto moderno. La mayoría de la gente ni siquiera recuerda que Flux era una cosa. El refresco rápido funciona genial. Y créeme, los líderes de pensamiento en Twitter no insisten en que deberías usar Redux hoy. Pero los conceptos de architecture y previsibilidad y observability siguen siendo muy relevantes mientras construimos aplicaciones.

Entonces, ¿cómo ha cambiado el React ecosystem? En 2015, el espacio del problema era realmente una discussion sobre la gestión del estado en el lado del cliente y también el concepto de efectos secundarios. Y en ese momento, los efectos secundarios incluían la obtención de data implícitamente, pero el ecosystem ha evolucionado. Probablemente alrededor de 2017, 2018, la discussion comenzó a cambiar de la gestión del estado en el lado del cliente y los efectos secundarios a la caché del estado desde el servidor, que es lo mismo pero con diferentes términos y una mentalidad diferente. Y así comenzamos a ver herramientas construidas con un propósito como Apollo y React Query que fueron diseñadas para resolver ese caso de uso particular. Y bueno, sí, el primer Redux era un poco difícil de usar y la gente lo ponía en todas partes, en muchos lugares donde no deberían haberlo hecho, y así la gente, como cualquier herramienta, pasó por una curva de adopción. Oh, aquí está la nueva cosa caliente que resolverá todos nuestros problemas. Espera, en realidad acabamos de encontrar un montón de nuevos problemas con la nueva cosa caliente. Y así la gente comenzó a descubrir que en realidad había problemas con ella. Y además de eso, a los desarrolladores más nuevos se les decía que tenían que usar esta cosa llamada Redux, pero nunca usaron ninguna biblioteca anterior y no conocían los puntos de dolor que Redux fue diseñado para resolver. Cuando Dan estaba escribiendo la documentación original de Redux, dijo, tengo que averiguar cómo explicar Flux a los desarrolladores de Backbone. Eso no es un problema que tengamos hoy en absoluto. También hemos visto un gran cambio de las aplicaciones de una sola página a la renderización en el lado del servidor, aplicaciones de múltiples páginas. Hay menos necesidad de un estado estrictamente en el lado del cliente. Tenemos muchas herramientas para obtener data en el servidor y tenemos bibliotecas de obtención de datos construidas con un propósito. También hay muchas otras soluciones para pasar data a través del árbol de componentes. El contexto moderno de React funciona muy bien. Hay muchas otras bibliotecas de gestión de estado como Joty y Zeustend y señales y todo lo demás. Así que hay muchas otras opciones para las cosas para las que la gente podría haber usado Redux en el pasado.

Pero, por otro lado, Redux también ha cambiado. Hemos pasado de la biblioteca original de Redux, que básicamente no tenía nada incorporado y tú tenías que escribir todo el código tú mismo, a Redux Toolkit, que proporciona APIs para básicamente todas las cosas comunes que haces con Redux. Crear una tienda, escribir reductores, obtener datos. Básicamente hemos resuelto el problema del código repetitivo y tenemos un montón de características incorporadas para prevenir errores comunes, como las mutaciones accidentales. Tenemos la biblioteca de consulta RTK para la obtención de datos. Enseñamos esto como la forma predeterminada de obtener datos con Redux hoy en día. No tienes que escribir thunks y reductores y sagas y todo este otro código solo para obtener algunos datos del servidor. Dices aquí está un punto final, aquí está la URL. Obtienes un hook que simplemente llamas en tu componente y hace todo ese trabajo por ti.

Nos hemos alejado de la API original de Conexión de React Redux a los hooks. Hoy en día React quiere que uses componentes de función y hooks. Vamos a seguir con eso. Los hooks son más fáciles de usar que la API de Conexión. Funciona mejor con TypeScript. Es un patrón de uso mucho más simple. React Redux tiene mucho menos código repetitivo hoy en día. El primer Redux no tenía opiniones reales. Dijimos aquí hay media docena de formas diferentes de hacer las cosas. Tú decides cuál quieres hacer. Eso significaba que diferentes bases de código de Redux temprano tenían una estructura muy diferente. Hoy en día tenemos la guía de estilo con un conjunto de patrones de opinión sobre cuál es la forma correcta de usar Redux. Enseñamos esos patrones con nuestras masterclass y con el uso de Redux Toolkit. Y enseñamos un enfoque de prueba que dice usar tu UI a través de la biblioteca de prueba de React y MSW y prueba tu código de Redux de esa manera. Todo tiene compromisos. Como desarrollador senior, esta es mi palabra favorita de todos los tiempos, compromisos. Hay puntos buenos y malos con cada herramienta. Nada es perfecto.

Como dijo Dan Abramov al principio, Redux está diseñado para responder a la pregunta, ¿de dónde vino una pieza de estado y por qué cambió? No está diseñado para ser la forma más rápida de ejecutar la aplicación. No va a ser la forma más corta de escribir el código, pero hace las cosas muy predecibles. Entonces, ¿cuáles son algunos de los compromisos de Redux? Con Flux, tienes esta indirección.

Envías una acción en lugar de decir que el valor del estado es 1, 2, 3. Esto significa que hay un poco más de code, tienes que ir y venir entre el componente UI y el reductor. Esto puede ser algo bueno. Significa que tu UI es más simple. Significa que puedes buscar en un solo lugar la lógica del reductor. Esto es más fácil de scale a medida que la aplicación crece, pero significa que tienes que entender que algunas cosas ocurren aquí y otras allá.

De manera similar, un único almacén es genial para tener un solo lugar donde buscar los data. Sabes dónde está la lógica del reductor, puedes verla en las herramientas de desarrollo, puedes tener lógica adicional basada en las acciones que se envían. Esto definitivamente puede ser abusado. El concepto de una única fuente de verdad probablemente se sobre enfatizó de alguna manera. Pongamos literalmente todo, cada valor individual incluyendo ¿está el desplegable abierto en Redux? Eso fue un poco demasiado, créeme. Además, Redux forum, Eric Rasmussen, te quiero, pero eso no fue una gran idea. Pero de manera similar, la idea de las actualizaciones de estado con reductores y segmentos. Esto significa que más del code en tu aplicación es puro y predecible, pero también significa que tienes que escribir estas actualizaciones inmutables, y a veces la lógica no siempre se divide de manera limpia. Y finalmente, gestionar el estado como objetos y valores JS simples. Esto significa que puedes serializar fácilmente los data, puedes persistirlos, pueden ser mostrados en las herramientas de desarrollo. A veces significa que, bueno, realmente desearía poder poner una fecha en mi almacén Redux o usar un conjunto o algo así, y realmente no se supone que debas hacer eso.

Bueno, el título de la charla es por qué deberías usar Redux hoy. Mentí. De muchas maneras, soy demasiado razonable para hacer el discurso de venta completo. Acabamos de hablar de compromisos. Es un poco difícil decir que deberías usar Redux de manera inequívoca cuando acabo de enumerar todas estas cosas que no son perfectas en él. Y honestamente, hay muchas otras herramientas geniales en el ecosystem. Así que en última instancia mi objetivo aquí no es decirte que literalmente deberías o deberías o debes usar Redux, sino más bien decir que Redux sigue siendo una opción muy válida hoy en día por muchas de las razones que hemos hablado. Así que terminemos con una rápida mirada a las cosas positivas de Redux que hacen que aún valga la pena considerarlo hoy. Proporciona un patrón arquitectónico muy consistente. Separar tu estado de la UI tiene muchos beneficios a medida que construyes aplicaciones del mundo real. El flujo de data es predecible. Sabes dónde buscar el code de actualización de estado real. Te da una mejor visión de lo que está pasando en la aplicación.

Puedes ver la historia semántica de las acciones. Las herramientas de desarrollo de Redux son increíblemente potentes. Es muy ampliamente utilizado. Odio usar esto como un argumento. Es como, bueno, es la biblioteca más popular. Todo el mundo la está utilizando. Deberías seguir utilizándola. Pero es un punto válido. Viste, básicamente todos en esta masterclass han utilizado Redux. La gente lo entiende. Está bien documentado. Esta es una razón válida para elegir una herramienta.

Es estable. Entiendes lo que está ahí. Actualmente tiene un rendimiento de actualización ligeramente mejor que el contexto de React. El próximo compilador de React ayudará con el rendimiento del contexto. Hay una discusión sobre una característica de selector de contexto. En este momento, se volverán a renderizar menos componentes si estás utilizando Redux que si estás utilizando el contexto de React. Existe Redux Toolkit. Hemos resuelto la mayoría de los problemas con los que se encuentran las personas cuando utilizan Redux hoy en día. Eso incluye la capa de obtención de datos de consulta RTK que hace que sea simple y directo decir aquí están los puntos finales, dame un hook, obtén los datos.

Finalmente, funciona muy bien con TypeScript. Hemos puesto mucho esfuerzo en asegurarnos de que nuestros tipos manejen toda la inferencia para que simplemente digas aquí está el tipo de mi estado, aquí está el tipo de mi acción, y funciona. Y aunque asumimos que la mayoría de las personas están utilizando Redux con React, todavía funciona sin React en muchas otras situaciones también. Estos no son necesariamente los argumentos más persuasivos del mundo. Podría hacer buenos argumentos para usar ZooStandard, Joe Tye, u otras herramientas. Pero estas son razones válidas para considerar el uso de Redux hoy en día y ejemplos de por qué sigue siendo la biblioteca de gestión de estado del lado del cliente más utilizada para React.

Eso es todo lo que tengo, y estoy bien pasado de tiempo, así que muchas gracias. Gracias. Gracias.

Gracias. Alguien preguntó, en realidad me gusta esta, ¿puede Redux ser completamente reemplazado, completamente con como estándar reduciendo el contexto, ¿y deberías? Esa es aproximadamente la millonésima vez que veo esa pregunta. Y en realidad lo acortaré un poco diciendo que he visto esa pregunta tantas veces que hace un par de años, escribí una publicación de blog titulada Por qué React Context no es una herramienta de gestión de estado y por qué no reemplaza a Redux. Ahora, la versión un poco más larga de eso es que sí, useReducer más useContext se ven muy similares a Redux, y tienen algunos patrones de uso similares. Hay diferencias significativas. Redux mantiene el estado fuera del árbol de componentes de React, y como acabo de mencionar, hay diferencias de renderizado en cuántos componentes se volverán a renderizar cuando pones un nuevo valor en el contexto versus tener un nuevo valor en la tienda Redux. Entonces, si no has visto esa publicación de blog, por favor échale un vistazo. Si buscas diferencias de Redux versus contexto, debería estar ahí, blog.isquaredsoftware.com. Escribí unas 6,000 palabras al respecto. Probablemente sea más fácil si lees esa publicación de blog. Es muy profundo.

Sí, brillante. Bueno, ¿cuáles son tus reglas para decidir si algo debería terminar en una tienda centralizada o no? La más grande es cuántos componentes en la aplicación probablemente van a necesitar acceso al estado. ¿Cuánto tiempo necesita vivir el estado, como necesitará el estado vivir más tiempo que algunos de los componentes en el árbol? ¿Con qué frecuencia se actualiza? ¿Tendré beneficios de ver las acciones que se despachan para entender lo que el usuario hizo? ¿Será realmente útil ver el estado en las herramientas de desarrollo de Redux? No hay una única regla dura y rápida. Como dije, puedes literalmente poner el estado de si el desplegable está abierto en Redux. Probablemente no sea genial porque realmente lo más probable es que solo un componente se preocupe y probablemente no necesite quedarse mucho tiempo. Mencionaste la previsibilidad de todo y eso parece que es la parte útil de todo el asunto, pero también viviendo fuera del contexto del componente en sí.

Entonces sí, genial. Esta ha subido en las listas. ¿Recomendarías Redux en absoluto al usar la renderización del lado del servidor? ¿Pregunta de nuevo? ¿Recomendarías Redux al usar la renderización del lado del servidor en absoluto? No estoy seguro. Entonces este es uno de esos casos en los que ciertamente es técnicamente posible hacerlo. No sé si lo recomendaría específicamente, por decirlo así. Entonces definitivamente tenemos ejemplos. Redux se ha utilizado en algunos casos de obtención de datos del lado del servidor desde el principio de la misma forma que incluso podrías usar el renderizado a cadena de React al principio. Usarías el mismo patrón básico. Crearías una tienda Redux, por cada solicitud individual, no la compartas entre solicitudes. Eso es malo. Despacha, creo, para hacer algo de obtención de datos, espera a que se complete. En ese punto la UI ha terminado de renderizar y luego podrías pasar los datos serializados de vuelta a la UI para hidratar la tienda en el lado del cliente. Entonces es absolutamente algo que puedes hacer.

Tenemos algunos ejemplos de ello. ¿Deberías hacerlo? Eso depende más de ti y de tu aplicación. ¿Estás usando Redux en absoluto? ¿Tienes necesidades de SSR? Genial.

Pasando a micro frontends. En una configuración de micro frontend usando federación de módulos, ¿qué tan pesado es inyectar dinámicamente reductores de las micro aplicaciones en la tienda global compartida? Vale. Así que una de las posibles ventajas de Redux, y este es un ejemplo de mover el estado fuera del árbol de componentes, es que es totalmente posible pasar la misma instancia de almacenamiento Redux a cada árbol separado de React en diferentes partes de una aplicación. Y todos verán el mismo estado. Añadimos una API en Redux Toolkit 2.0 que está diseñada para ayudar con la inyección dinámica de reductores en la tienda. Es una API llamada combine slices, y en realidad facilita la inyección de reductores que algunos de los patrones escritos a mano más antiguos también. Genial. Gracias. Vale. Con el estado del formulario, el estado de la url, y la obtención de datos asíncronos como su propio estado, ¿qué queda realmente para que Redux gestione? Esta es una excelente pregunta. Esto vuelve a mi punto. Como, sí, podrías poner literalmente cualquier cosa en Redux, y desafortunadamente, la gente lo ha hecho en diferentes momentos. Pero si, como, especialmente con el estado del servidor, eliges usar una herramienta como React Query para gestionar tu obtención y almacenamiento en caché del estado del servidor, todo lo que queda es una pieza más pequeña del estado del cliente en ese punto, y probablemente no necesites usar Redux para una pieza relativamente más pequeña del estado del cliente. Ahora, podrías usar Redux para todo eso, RTK Query para la obtención de datos, más algunas slices adicionales para todo en el cliente, pero hay herramientas que están especializadas para cada pieza. Así que, de nuevo, es por eso que no puedo en buena conciencia quedarme aquí y decir, como, debes usar Redux, porque hay diferentes herramientas que son buenas para las mismas cosas. Así que Redux proporciona RTK Query para la obtención de datos. Proporciona create slice para el estado del lado del cliente. Si eliges usar Redux, funcionará bien, pero si has elegido usar algo como React Query o lo que sea, entonces has eliminado quizás algunas de las razones por las que podrías haber elegido Redux en el pasado. Me gusta. Nada en tecnología es nunca, debes usar esto al 100%, ¿verdad? Supongo que estamos en React Summit, pero entonces el discurso de apertura fue sobre solid. Depende siempre es la respuesta, ¿verdad? Sí. ¿Cuál es un buen ejemplo de cuándo no deberías usar Redux? El estado del formulario es uno bueno. Como dije antes, la comunidad de Redux intentó poner Redux en todas partes al principio, y eso incluía la biblioteca de formularios de Redux, y en retrospectiva, despachar acciones en cada pulsación de tecla no fue una gran idea. Para los formularios de hoy, diríamos que simplemente uses el estado de los componentes locales o incluso, como, componentes no controlados, React forms, algo así. Porque estás editando el formulario, y luego despachando la acción al final con la actualización diciendo que ahora está hecho, ahora el resto de la aplicación puede usarlo.

Haz lo que quieras con ello. Genial. No lo uses para forms. Para actualizar el estado del formulario. Sí. De acuerdo.

¿Es RTK query siempre la opción a seguir, o hay casos en los que usar simplemente fetch es mejor? Bueno, eso es una pregunta un poco falsa. RTK query, por un lado, es un administrador de estado asíncrono de propósito general. TK Dodo, el autor de React query ha escrito algunos posts diciendo que no es una biblioteca de obtención de data, es un administrador de estado asíncrono, porque simplemente es una promesa, rastrea el estado, guarda el resultado en caché. RTK query es lo mismo. Por defecto, tenemos un envoltorio de fetch como la forma predeterminada de usarlo, pero puedes usarlo para cualquier función asíncrona de promesa en absoluto. Ciertamente enseñamos RTK query como la forma predeterminada de hacer cualquier obtención de data en una aplicación Redux. Es una herramienta, tiene sus límites, y probablemente hay algunos casos límite en los que podrías necesitar escribir algunos thunks u otra lógica en su lugar.

Eso nos lleva a una pregunta más adelante, que en realidad se sale un poco de esa obtención de data, supongo, y pregunta, como, ¿sería bueno Redux en el backend para cosas como Web sockets y juegos en absoluto? Eso va a lo que estaba diciendo antes. Redux en sí, el núcleo es totalmente agnóstico a la UI. Siempre hemos asumido que, como, el 90% de nuestros usuarios lo usarán con React, pero puedes usar Redux en cualquier lugar que se ejecute JavaScript, con o sin ninguna UI. Y sí, he visto a gente usarlo, como, en bots de Discord para mantener un seguimiento del estado. Sí, y los Web sockets no hacen diferencia o escribes tu propio... Es lógica, despachas acciones, se ejecuta. Genial. Ya hemos cubierto el uso de context antes, voy a pasar de eso. Redux Saga me permite abortar la obtención, ¿es eso posible en RTK query? Veamos, ¿qué? Redux Saga me permite abortar la obtención, ¿es eso posible? No exactamente. Así que esto ha surgido bastante frecuentemente en los problemas y solicitudes de características relacionadas con RTK query. Nuestra postura hasta ahora ha sido que no hay suficiente razón para abortar una obtención de data porque el resultado se guardará en caché y aunque un componente ya no diga que necesita esa data en este momento, podrías volver y necesitarla más tarde, es simplemente otra entrada en la caché, y si ningún componente la necesita, se recogerá como basura más tarde. Hemos tenido suficientes solicitudes para abortar, como, literalmente abortar una solicitud de obtención que es algo que podríamos considerar añadir en una versión futura. Genial, es bueno saberlo. Y si quieres eso, supongo que envía una solicitud también? No hay más problemas, no hay más problemas. ¿Solo un pulgar arriba en uno existente? Sí, por favor. No más nuevos problemas con eso, genial.

Oh, esto es interesante. ¿Hay un plan para tener paquetes Redux en JSR? No específicamente. Para aquellos que no tienen contexto, JSR es un nuevo registro de paquetes JavaScript, una especie de competidor de NPM creado por la gente de Dino. Puedo intentarlo. Honestamente no es algo en lo que haya invertido tiempo o pensamiento, como si alguien quiere presentar un PR y ayudarme a hacer eso, sería genial. Todavía no he subido nada a JSR, pero por lo que he visto en los docs, no parece demasiado difícil. También pasé todo el año pasado luchando con nuestro packaging y realmente preferiría no volver a eso en cualquier momento pronto. Un poco de PTSD en la gestión de paquetes. Escribí una entrada de blog de 7,000 palabras sobre todos los problemas que encontré tratando de hacer que ESM funcionara correctamente. Creo que leí esa, sí. Cosas estupendas. Sí, supongo que JSR se supone que es más fácil que eso. Eso espero. Sí. Esperemos que no sea mucho más fácil. No puede empeorar.

Bueno, creo que eso es... Probablemente se nos acabe el tiempo. Sí, correcto. Sobre el horror de la gestión de paquetes, terminaremos allí. Muchas gracias, Mark. Por favor, den otra ronda de aplausos a Mark.