From Redux to Zustand to Jotai to Zustand to Custom: Nuestra Historia de Horror de Gestión de Estado

Hoy, quiero contarles sobre cómo hicimos una especie de historia de terror que llamamos nosotros mismos y sobre cómo cambiamos nuestra infraestructura de gestión de estado demasiadas veces. Así que vamos directo al grano.

¿De qué estamos hablando? Estamos hablando de este producto en el que estoy trabajando llamado Plux. Y es un software CAD, CAD eléctrico muy agradable para la web. Básicamente, puedes diseñar circuitos, diseñar electrónica, los esquemas, el PCB. Es como si hubiera mucho en juego y puedes crear conexiones y simular circuitos. Es genial.

¿Y por qué estamos hablando de esto aquí hoy? Bueno, porque está construido sobre tecnologías que supongo que muchos de ustedes conocen. Es una aplicación de TypeScript. Tenemos como medio millón de líneas de código de TypeScript y está construida con React, tanto la parte de la interfaz de usuario como la parte del lienzo 3D. Está construida con Three.js y React 3.0 Fiber. Así que en realidad estamos construyendo una herramienta CAD gigante sobre React 3.0 Fiber. Y una pregunta que he escuchado algunas veces de personas con las que hablo es, está bien, React, pero ¿cómo manejas el estado? ¿Estás usando dos ganchos estándar de Redux? ¿Qué estás usando? Y mi respuesta a eso es de una manera meme, sí. Estamos usando un montón de diferentes bibliotecas y las cambiamos bastantes veces.

¿Y por qué cambiamos de bibliotecas demasiadas veces? Bueno, fue un proceso de descubrimiento. Y esto se debe a que nuestro producto es bastante desafiante. Queremos soportar documentos enormes, que como 10,000 partes electrónicas, cada una es un modelo 3D con propiedades y cosas. Y queremos soportar interacción en tiempo real. Así que puedes hacer clic y arrastrar todo y el multijugador, como lo que haces con Figma y Google Docs, puedes simplemente editar algo y todos los demás lo verán. Y tenemos un sistema complejo de reglas de cascada, como cada componente electrónico tiene dependencias entre ellos. Y estamos ejecutando un montón de cálculos en segundo plano, como calcular propiedades eléctricas, calcular geometría, y todo eso se está ejecutando en WebWorkers. Y tenemos este tipo de canalización de datos, porque estamos procesando nuestros datos mucho antes de poder mostrarlos a los usuarios.

Y hay dependencias extrañas entre los datos y todos esos desafíos con el objetivo de poder ejecutarlo a 60 fotogramas por segundo en hardware medio, lo cual fue increíblemente difícil de hacer. Así que hablemos del comienzo. ¿Dónde comenzamos con esa gestión? Bueno, con Redux, por supuesto, amamos Redux. Todavía lo usamos hoy. Y la razón por la que usamos Redux es porque es nuestro repositorio para datos persistentes. Todo el documento que viene del servidor y luego regresa al servidor, se persiste en Redux, lo que nos permite hacer algo bastante genial. Tenemos multijugador automático y persistente y sincronización con el backend. Cada vez que realizamos una acción en Redux, todos los que, todas las demás personas que están visitando ese enlace podrán recibirlo en su extremo. Así que no tenemos que preocuparnos por eso, porque cada desarrollador puede simplemente enviar las acciones a Redux y se persistirá y transmitirá automáticamente. Y estamos haciendo eso con RxJS y Epix. Pero no quiero entrar demasiado en eso hoy, porque quiero contarles la historia de cómo lo cambiamos.

Y la razón es porque en un cierto punto, comenzamos a desarrollar un nuevo editor, el editor de PCB, que era mucho más complicado que el que teníamos antes. Y teníamos la necesidad de datos derivados, lo que significa tomar los datos del documento y procesarlos. Y normalmente, lo que harías es que simplemente lo harías en tu renderizado. Pero necesitábamos estos datos en toda la aplicación. Necesitábamos poder acceder a esos datos para interacciones. Por ejemplo, la posición de un nodo, o también necesitábamos poder exportar esos datos en diferentes formatos estándar de la industria. Así que no podíamos hacer algo tan simple como obtener los datos de Redux y simplemente renderizarlos tal como están. Pero necesitábamos hacer algo un poco más complicado. Necesitábamos procesarlos y almacenarlos en algún lugar. Y ese lugar iba a ser utilizado por muchos sistemas diferentes. Renderizado, interacción del usuario, exportación. Y estábamos pensando, ¿qué debería ser ese algo? Como que parece un caché o un almacén. Por eso introdujimos GSDAN, que es este oso genial y el hermano más genial de Redux. Es una biblioteca de gestión de estado. Supongo que otras personas han oído hablar de ella. Que es bastante más fácil de configurar y mantener. Como que tiene mucho menos código boilerplate. Y la razón por la que elegimos esto, es porque escuchamos que esto iba a ser más rápido que Redux. Tal vez. No estábamos realmente seguros, pero teníamos que empezar en algún lugar. Así que comenzamos con esto.

Y para discutir el rendimiento, traeré un ejemplo clásico. En nuestra aplicación, tenemos muchos nodos diferentes, que son como los elementos. Y queremos, por ejemplo, renderizarlos en una lista o renderizarlos en el lienzo. ¿Cómo harías eso con React? Bueno, comienzas creando una tienda, que está aquí, SUSAN Store. Creas tu componente de renderizado para tu nodo, que se suscribe a la tienda con este nuevo gancho de tienda. Y luego recorres todo tu estado con un mapa y renderizas todos tus nodos. Suficientemente simple. Pero probablemente notaste que ya hay un error de novato aquí. Si estamos haciendo eso, entonces básicamente nos estamos suscribiendo a toda la tienda porque no estamos usando un selector allí. Entonces, ¿qué pasa? Cambiamos un nodo y todo se renderiza, porque una tienda usada es básicamente una suscripción global. Y la solución para eso es, por supuesto, usar un selector, que es este tipo de función lambda que nos permite decirle a SUSAN qué parte de la tienda nos interesa. Y los selectores han sido discutidos mucho, como hay una página entera en la documentación de Redux sobre eso. Lo que significa que podemos ir aún más profundo. Tal vez no queramos suscribirnos a un nodo completo, sino incluso a una sola propiedad de un nodo para que podamos reducir aún más los renders. Así que reemplazamos esto y ponemos todo dentro de la función lambda del selector así. Y eso es en realidad algo bastante común que verás en muchas aplicaciones. Y tomamos esto un poco religiosamente en Flux. Teníamos el objetivo de reducir los renders tanto como fuera posible. Así que creemos selectores más complicados. Creemos un selector que tenga un bucle dentro de ellos. Y una vez que llegamos a esto, estábamos pensando, ¿estamos seleccionando demasiado? ¿Estamos tratando de reducir tanto los renders que nuestro selector se convirtió en el problema una vez más? Bueno, la razón por la que hicimos eso es que comenzamos con esta suposición, que es de lo que todos hablan. Los renders de React son costosos. Quieres evitar los renders de React. Así que haces lo que sea necesario para reducirlos. Pero nos preguntábamos, ¿qué pasa con esto? ¿Qué pasa con esta parte del selector en sí? Porque cada vez que usas un selector, esos selectores tienen que ejecutarse. Cuando haces un set state en Zoostand, se llaman a todos los selectores. Y todos los selectores que se evalúan luego deben compararse con el valor anterior. Así que casi estás renderizando todo. Solo que estás filtrando en la última etapa. Y nos preguntábamos, ¿puede esto convertirse en un problema? Bueno, tenemos documentos con 2,000 nodos.

Cada nodo tiene como 20 store hooks, lo que significa muchas suscripciones. Y luego también introdujimos que algunos selectores se volvieron de complejidad O-N. La interacción del usuario ahora toma 10 segundos. Felicitaciones, tu software es lento. Y así nos dimos cuenta de que, sí, tal vez tenemos que cambiar algo. No puede ser que presiones un botón y tengas que esperar 10 segundos.

Y de hecho, miramos el perfil, y estamos como, set state, listener. Eso es toda la evaluación del selector. ¿Qué está pasando aquí? ¿Por qué set state toma ocho segundos? Eso es porque los selectores a veces pueden volverse costosos cuando tienes como 200,000 de ellos. Y lo sé, es un caso extremo. Pero básicamente, mi trabajo es constantemente lidiar con casos extremos. Así que nos preguntamos, OK, usar ese tipo de hooks con selectores es básicamente todavía una suscripción global. ¿Qué pasaría si pudiéramos hacer una suscripción granular? ¿Qué pasaría si pudiéramos suscribirnos solo a una parte de la tienda sin usar selectores, tal vez simplemente activando el correcto de inmediato?

Bueno, lo que descubrimos es que la razón por la que la biblioteca de gestión de estado usa tanto los selectores es porque si los usas, tu biblioteca de gestión de estado no necesita saber qué hiciste en tu set state. Déjame darte un ejemplo. Implementemos un pequeño do stand en el que tenemos nuestro estado, nuestros oyentes globales, y nuestra función set state. En nuestra función set state, simplemente llamamos a la transición de estado, el reductor. Y luego llamamos a todos los oyentes. Supongamos que queremos ser un poco más inteligentes y solo llamar a los oyentes que se preocupan por lo que cambió. ¿Cómo sabríamos qué sucedió en la función de transición de estado? No tenemos idea de qué parte del estado cambió. Necesitaríamos realizar una gran diferencia, lo cual no es factible. Así que básicamente quedó claro que Zustand no era el modelo adecuado para nosotros. Es un gran modelo para aplicaciones web automáticas, pero tal vez no para nosotros. Así que es hora de reemplazar Zustand. ¡Yay! Primer refactor. Y analizamos algunas alternativas, y una alternativa que parecía muy, muy prometedora era Jotite, que es otra biblioteca de gestión de estado muy interesante. Cómo funciona es que es muy similar a Recoil. Probablemente ya hayas oído hablar de esto. Existe este concepto de múltiples átomos de estado diferentes en lugar de uno solo. Y te permite modelar datos calculados como átomos derivados, básicamente una suscripción o una suscripción, lo que te permite modelar datos de una manera un poco diferente. Y la forma en que logramos vender esto a la gerencia y convencerlos de que necesitábamos un refactor fue que esta era una nueva biblioteca brillante que era un, hey, tal vez esta cosa que está probada por la industria podría resolver nuestros problemas.

Y eso fue un gran caballo de Troya para hacer un poco de trabajo de rendimiento. Así que lo que hicimos fue tomar este modelo con Zustand que llamaba a todos los suscriptores todo el tiempo, y en su lugar, pasamos a átomos en los que ahora finalmente podemos simplemente llamar al procesamiento en ese átomo específico y ser mucho más precisos con una suscripción. Y para probar que este era el caso, simplemente hicimos un pequeño sandbox, como un repositorio diferente comenzado desde cero. Y parecía muy prometedor, como un enfoque con Redux a un segundo para la interacción, mientras que un enfoque con Jyoti tomó solo 70 milisegundos, lo cual fue mucho, mucho más rápido. Así que esto fue definitivamente un éxito. Implementémoslo. Y fuimos e hicimos este gran refactor para adoptar Jyoti en lugar de Zustand.

Pero luego nos dimos cuenta de que todavía teníamos que mantener Redux porque de lo contrario sería demasiado de una reescritura. Así que todavía tenemos eso en cuenta. Y luego nos dimos cuenta de que, bueno, cada nodo no es independiente. Podemos tener un nodo que es hijo de otro nodo, de modo que tienes que actualizar juntos. Así que tendríamos que escribir un código que sea capaz de rastrear cada dependencia. Así que no, eso no habría sido posible. Y luego nos dimos cuenta de que algunas cosas que son realmente simples, como obtener el valor actual de manera transitoria, o obtener el valor de todos los nodos al mismo tiempo se volvió demasiado complicado. Así que resultó que tuvimos que sortear las limitaciones de Jyoti. Y después de la migración, fue peor que Zustand, lo cual fue divertido. Así que lo que pasó es que lo revertimos. Pero en realidad, no, solo revertimos los cambios de Jyoti porque, ya sabes, cuando hicimos esta gran migración, nos vimos obligados a hacer refactores para adaptarnos a este nuevo modelo de datos. Y estos refactores que hicimos fueron realmente útiles. Así que logramos vender un mejor rendimiento con una nueva biblioteca de gestión de estado que no existía. Y obtuvimos un buen refactor en el proceso que nos ayudó enormemente en el futuro.

¿Cómo? Alguien dentro de la empresa hizo una pregunta extraña, bueno, ya sabes, como si un solo hilo que procesa todos los datos es lento, ¿qué pasa si divides los datos en múltiples hilos y los procesas independientemente? Bueno, no realmente. Pero la pregunta era, ¿qué pasa si dividimos la tienda de Zustand? Como si una tienda tuviera que disparar todas las suscripciones, ¿qué pasa si dividimos la tienda en tiendas Zustand más pequeñas para que cada una tenga su propio subconjunto de nodos y tenga que llamar a menos suscripciones? Bueno, resulta que alguien más ya habló de esto. Y de hecho, entonces Abramov dijo que es una mala idea, a menos que tengas problemas de rendimiento. Como si tuvieras miles de elementos que están en pantalla al mismo tiempo, eso somos nosotros. Así que eso es exactamente lo que hicimos. Veamos cómo funciona. En primer lugar, hicimos una función hash, que, dado un nodo, te da cuál es la partición. Así que luego podemos mapear de manera constante, siempre el nodo a la partición. Luego creamos una tienda Zustand para cada una de esas particiones.

Y luego, cuando quieres usarlo en React, tienes que obtener la tienda para ese nodo específico y suscribirte a él. Eso podría parecer extraño o un poco complicado, pero los resultados estaban ahí. Una interacción que antes tomaba ocho segundos. Ahora tomó 38 milisegundos, así que como una mejora de 200x, lo cual fue realmente agradable. Y así pensamos, básicamente, en lugar de tener tu rendimiento dependiendo del número de nodos, ahora es el número de nodos dividido por el número de particiones. ¿Qué pasa si hacemos p igual a n? ¿Vamos a tener 0,1? ¿Qué pasa si hacemos una partición por nodo? Así que hablamos de esto con algunas personas y un consultor. Que dijo que básicamente, ahora mismo, desafortunadamente, no hay una biblioteca de código abierto que haga eso porque no somos el 99% de lo que son las aplicaciones hoy en día. Pero estamos haciendo algo que empuja un poco los límites de la plataforma web. Así que tal vez necesitemos una nueva forma de pensar sobre el problema. Y esta fue nuestra excusa para vender otro refactor. Entonces, ¿qué hicimos? Creamos nuestra propia tienda. Decidimos ir completamente personalizados, lo cual en realidad fue muy simple. Fue como una versión abreviada de lo que estamos usando. En realidad, es un poco más complicado, pero entiendes la idea. Es que tenemos una tienda que lleva un registro de todos los nodos y para cada nodo, quién está suscribiéndose al nodo con un Wikmap. Y cuando hacemos el set state, no hacemos un set state en todo el estado, sino solo en un solo elemento para que podamos llamar con precisión al suscriptor que está interesado en ese cambio. Y no podíamos hacer eso antes del refactor de Jotai porque no teníamos esa información. Y ahora finalmente la tenemos. Cambiamos todo nuestro sistema para soportar esto. Y aún podemos tener una instancia de historia global o inyectarla con un contexto como lo harías con Toast o Redux. Y cuando quieres usarlo con React, básicamente lo que haces es que te suscribes y luego en el cambio, estableces el estado. O hay una API muy interesante que React ha tenido por un tiempo, pero no sé si alguien sabe sobre ella, que es useSyncExternalStore, que es un hook específico al que puedes pasar la función de suscripción y la función para obtener una instantánea. Y eso es prácticamente todo. Básicamente puedes implementar un puente entre React y la biblioteca de gestión de estado de esa manera. Los resultados fueron asombrosos porque además de la mejora de 200x que tuvimos antes, ahora tuvimos otra mejora de 200x. Y finalmente, hicimos lo que juramos que nunca haríamos, que es la solución personalizada, y en realidad funciona muy bien para nosotros. Entonces, ¿esto significa que Zustan, Jotai, Redux son malos? No, son increíbles para lo que hacen. Son increíbles porque son rápidos y tienen algunas limitaciones de rendimiento, por supuesto, pero esas limitaciones de rendimiento son exactamente lo que te permite desarrollar más rápido. Imagina si todos tuvieran que modelar con precisión sus datos y luego construir una solución personalizada sobre eso, no sería factible. Pero las bibliotecas existentes, tienen una abstracción.

Pueden forzar una obstrucción en ti. Y a veces la obstrucción puede funcionar, pero a veces no. Y creo que es muy importante averiguar cuándo es el caso. Cuando descubres que esa obstrucción no funciona para ti, porque creo que es muy fácil simplemente cegarse por el, oh, no podemos hacerlo de manera diferente y simplemente construir sobre cosas que no funcionarán para ti.

Y lo último es que tal vez no te encierres en la solución. Pero incluso si lo haces, no importa porque la migración y la solución personalizada son posibles. Como lo hicimos, aunque pensábamos que no sería un gran viaje. Y lo fue, pero fue inmensamente bueno para nuestro rendimiento. Y a veces incluso haces amigos en el camino. A veces haces una migración, falla y te quedas con un gran factor y un gran aprendizaje que te ayuda en el futuro. Así que, gracias.

La primera pregunta es ¿cuál fue el cronograma para todo este conjunto de cambios desde ir a Redux hasta soluciones personalizadas? Un año y medio, creo. ¿Cuánto tiempo entre cada uno de esos pasos, sin embargo? Básicamente, en el momento en que terminamos uno, inmediatamente reconocimos que necesitábamos algo diferente. Eso se siente como la historia de mi vida. Y también como ligeramente caótico, imagino que debe... ¿Cómo interactuó este trabajo con el trabajo diario en otras áreas? Quiero decir, esa es una pregunta interesante porque mucha gente usa esos datos. Y así tienes que gestionar un poco el hecho de que tenías PRs pendientes que estaban a punto de fusionarse, para ser fusionados usando la API antigua. Así que tienes que congelar un poco todo. Pero afortunadamente, el colega que hizo esos refactores básicamente cambió el código para ellos, lo cual fue increíblemente agradable. Así que a veces solo tienes algunos ángeles en tu empresa que hacen las cosas realmente bien. Permitiéndote pasar de una herramienta de gestión de estado a otra. Bien, así que la siguiente pregunta aquí es ¿cuándo planeas hacer open source? Necesitamos más de una biblioteca de gestión de estado. Quiero decir, podríamos absolutamente hacer open source. Solo que al final, nuestra solución está muy adaptada a lo que estamos haciendo. Y creo que será un poco como, si hacemos open source, será como si lo publicamos como un gist en algún lugar, hey, aquí está cómo podrías implementarlo como un ejemplo. Pero creo que si realmente quieres hacer open source algo y tienes que mantener eso, y no tiene sentido si luego no vamos a adoptarlo en primer lugar porque tenemos demasiado miedo de luego tener que estar atados a algo que no podemos cambiar en el futuro. Sí, estoy completamente de acuerdo en lo que vale. Hacer open source código que viene con un conjunto completo de expectativas que necesitas cumplir. Pero si todos están interesados en saber cómo funciona internamente, solo pregúntame. Probablemente pueda mostrar algo.

Bien. Muy bien. Siguiente pregunta, que es un poco graciosa en el contexto de tu charla. ¿Es realmente necesaria la gestión de estado? ¿No es la mejor gestión de estado usar state y usar reducer, no es así? Sí. Me alegra que hayamos sacado eso del camino. Gracias a todos.

Bien. Así que siguiente pregunta. Y estas van en términos de las preguntas con más pulgares arriba. Así que si estás interesado en ver algunas específicas, esa es tu señal para entrar en Slido y hacerlo. ¿Qué hay de MobX? ¿Fue una consideración? Tengo que admitirlo. Nunca lo investigué. Lo siento mucho. Quiero decir, esa es una respuesta legítima como cualquier otra, para ser completamente franco.

¿Cómo encontraste las herramientas entre las que terminaste moviéndote? Como, ¿cómo llegaron primero, si realmente no investigaste MobX, tengo curiosidad, cómo los otros llegaron a tu órbita en primer lugar? ¿Quién? ¿Te refieres a cómo encontramos Jotai y? Sí. Bueno, porque básicamente lo que hicimos es que, quiero decir, estábamos un poco gravitándonos alrededor de ese conjunto de bibliotecas, que es como hecho por ese equipo de open source que también hizo React ReFiber. Pero también nos dimos cuenta de que eventualmente teníamos que hacer una solución personalizada. Así que miramos un poco alrededor, pero no demasiado porque estábamos probando algo y probablemente estábamos pasando de una biblioteca a la siguiente antes de hacer una selección precisa. No, eso tiene sentido.

Muy bien. Así que una pregunta similar que podría terminar teniendo una respuesta similar. Creo que para la mayoría de los sitios web usar context es suficiente. ¿Por qué deberíamos usar algo como Redux? Bueno, en realidad estoy absolutamente de acuerdo con eso porque creo que Redux y solo en las bibliotecas como esa te ayudan porque te permiten tener algún tipo de pieza de código muy aislada que maneja tu estado y puedes aislar ese código muy bien. Y la otra cosa es que con usar context es mucho más complicado trabajar con él si tienes sistemas que son independientes de él. Como si tienes un trabajador web que está ejecutándose en paralelo y que se supone que debe poner los resultados de algo en un estado. Creo que es un poco más fácil hacerlo con el Zustan que simplemente usar un usar context. Así que es un poco de un ejecting de React. Sí.

OK, siguiente pregunta. ¿Qué piensas de crear un paquete para tu gestión de estado personalizada, venderlo y luego crear otro para reemplazarlo? Vi que ese patrón sucedía algunas veces.

Siento que esa es la secuela de esta charla. Esa es la charla del próximo año, ¿verdad? ¿Has considerado usar signals en tu trabajo? No realmente, pero eso podría ser una idea, de hecho, porque creo que es similar a lo que estamos haciendo, de hecho. Sí.

OK, wow. Hay muchas preguntas y no mucho tiempo. Así que solo un recordatorio antes de que haga tal vez la última o dos preguntas que después de esta sesión, si estás aquí en el espacio y hay un espacio de preguntas y respuestas para el orador cerca de la entrada y ahí es donde puedes hacer más preguntas.

¿Cómo reconoces los problemas de rendimiento? ¿Cómo reconociste que los problemas de rendimiento se debían a las bibliotecas de gestión de estado? Sí, fue un poco de debate también dentro de la empresa porque la gente decía, bueno, no creo que ese sea el caso. Y la gente decía que sí, ese es el caso. Y al final, es mucho de hacer perfiles. Es mirar lo que está sucediendo dentro de, como cuando haces un perfil de una interacción y ves cuál es el conjunto de funciones que se están llamando. Y porque a veces es como que es muy claro en el momento que estás viendo que haces una acción y la mayor parte de tu tiempo se gasta durante la etapa de escucha. Y luego ves que todos los selectores se están ejecutando uno tras otro. Y uno toma un poco de tu tiempo de perfil. Esa es la forma en que lo descubrimos, básicamente, solo a través de hacer perfiles. Sí. Y un poco de trabajo de detective también. Sí, exactamente. El trabajo de detective es, haces un factor y luego ves si realmente mejoró o no. Y descubrir si teníamos razón. Genial.

Bueno, eso es todo el tiempo que tenemos para preguntas. No te vayas a ningún lado. Tengo algo muy importante para este grupo. Así que no te escapes todavía. Pero antes de terminar, ¿podemos dar un gran aplauso a Giulia por una fantástica charla? Muchas gracias. Si te diriges al viernes 6.