Historia de Desarrollo de Zustand

Hola, esta charla trata sobre la historia de desarrollo de Zestand y cómo estuve involucrado en ella. Por cierto, lo pronuncié Zestand, pero no está definido cómo deberíamos pronunciarlo. Podemos llamarlo como queramos.

Para aquellos que no lo sepan, Zestand es una biblioteca de gestión de estado para React.

Para empezar, permítanme presentarme. Soy Daishi Kato. Soy un freelancer al que le gusta programar, especialmente el software de código abierto. He realizado muchos trabajos de código abierto. La mayoría de ellos comenzaron como experimentos. Algunos de ellos llamaron la atención y se convirtieron en proyectos bastante conocidos. Zestand es la biblioteca de la que hablamos hoy. Jyotai es otra biblioteca de gestión de estado de la que di una charla anteriormente. Valusio es otra biblioteca. Las tres fueron desarrolladas con un equipo llamado Poimanderes. La última se llama Reactract, que es uno de mis grandes proyectos explorando los hooks de React. Hay muchas otras bibliotecas pequeñas. La mayoría de mi trabajo reciente es con los hooks de React. Pero también tengo un interés más amplio en JavaScript en general.

De todos modos, la charla de hoy trata sobre Zestand. Zestand es uno de los proyectos exitosos. Es una biblioteca de gestión de estado, y hay muchas bibliotecas similares disponibles. Debido a que hay tantas, dar a conocer y hacerse popular es un gran desafío. Afortunadamente, Zestand ha llamado la atención hasta ahora. Supongo que es solo suerte. No estuve involucrado en el desarrollo original de Zestand, pero estaba haciendo algo muy similar en aquellos días. Fue en 2018. React anunció los hooks en React Conf 2018 en octubre. Fue una gran inspiración y desarrollé varias bibliotecas con hooks, algunas de las cuales eran para la gestión de estado. Antes de los hooks, había desarrollado una biblioteca con el contexto de React, al igual que otros. Tomé el mismo enfoque y creé una versión con hooks de ella.

Mientras lo desarrollaba, sabía que no requería el contexto de React porque el caso de uso es el estado global. Los usuarios nunca tendrán componentes proveedores anidados. En realidad, hice una versión sin contexto, pero no fue bien recibida por los usuarios en ese momento. Y el tiempo pasó.

Fue en abril de 2019 cuando se lanzó la versión inicial de Zastand. Aún estaba en una etapa inicial, pero obtuvo algunos usuarios. Con la colaboración de algunos colaboradores, se lanzó la versión 1 en junio. Poco después, lo encontré en algún lugar. En ese momento, tenía una herramienta, un repositorio, para comparar varias bibliotecas de estado global. Se construyó para verificar el comportamiento del renderizado concurrente. La herramienta se utilizó para verificar mis bibliotecas y algunas otras bibliotecas populares. Así que también agregué Zastand allí. Zastand era único ya que no utilizaba el contexto de React en absoluto. Todos los demás utilizaban el contexto para la propagación del estado o el alcance de las tiendas. Creo que el contexto de React se ha utilizado en exceso para el estado global. A menos que uses proveedores de contexto varias veces en tu árbol de componentes, no es contextual. El estado global definido a nivel de módulo debería funcionar correctamente. Zastand fue un pionero en este enfoque. Estoy convencido de ello y reimplementé una de mis bibliotecas. Más tarde, escribí una publicación de blog detallada al respecto. En fin, así es como conocí a Zastand. Como dije, uno de mis repositorios para comparar varios estados globales en el renderizado concurrente.

Estaba interesado en hacer que Zastand sea más compatible con el renderizado concurrente para futuras versiones de React. Me uní al equipo en agosto de 2020 y me hice cargo del desarrollo de Zastand. Zastand había sido desarrollado activamente en el año anterior y alcanzó la versión 2. Sin embargo, en realidad no fue mantenido después de eso. Había una cierta cantidad de usuarios y algunos problemas abiertos, pero nadie se encargaba de ellos. Mientras mi motivación era el renderizado concurrente, comencé a mantenerlo y resolver esos problemas. La versión 3 se lanzó en el mismo mes en que comencé a trabajar en ello. Tenía dos grandes mejoras, pero aparte de eso, es básicamente compatible con la versión anterior.

La buena noticia es que me familiaricé con el código base. Después del lanzamiento, solucionamos varios problemas pequeños. A medida que se hizo popular, obtuvo más usuarios, más colaboradores y más problemas. Mejoramos muchas cosas pequeñas y más personas estaban interesadas en probarlo.

En algún momento, comenzamos a preparar la próxima versión. Realizamos muchos experimentos y duplicamos algunas características antiguas. La próxima versión es para el renderizado concurrente, que fue mi motivación original. En ese momento, se lanzó React 18, con un nuevo gancho llamado useSyncExternalStore. Hubo una larga historia detrás de eso, pero ese gancho es un sucesor de nuestra solución ejecutada por el usuario. Zestand V4 se lanzó con ese gancho. En realidad, utiliza la biblioteca de compatibilidad proporcionada por React, por lo que funciona con React 17. La implementación de la biblioteca está casi completamente reescrita en V4 en comparación con lo que teníamos en V2 antes de unirme. Los tipos de TypeScript han mejorado mucho, gracias a un colaborador. Ha sido un gran viaje llegar hasta aquí. Aprendí varias cosas, no solo programación, sino también el crecimiento de la comunidad. Agradezco a todos los que participaron en este proyecto.

En este momento, el estado de este proyecto es bastante estable. Especialmente, la implementación principal está básicamente terminada. Algunos middleware como Persist aún tienen margen de mejora y buscamos colaboradores. Hay una gran demanda para mejorar la documentación y estamos trabajando en ello. Consideraremos las versiones futuras una vez que entendamos cómo avanza React. Especialmente, no estamos seguros acerca del gancho use propuesto. Aún no está claro qué vendrá después. Lo que se hará, con seguridad, es eliminar características duplicadas. Probablemente eliminaremos la compatibilidad con React 17 en la próxima versión principal.

Volviendo un poco atrás, hablemos de qué es Zastand. Después del desarrollo, mi conclusión es que Zastand es una respuesta a una pregunta. La pregunta es, ¿cuál sería la biblioteca de estado global más pequeña posible para React? Para agregar un poco más de requisitos, sigue los principios de Flux, es menos dogmática y aún es extensible. Por lo tanto, una API pequeña y un tamaño de paquete reducido son las claves en Zastand.

Está construido sobre estados inmutables, al igual que React. De hecho, crear un clon de Zastand es una tarea muy fácil. Podrías agregar varias características encima de él. Mantenerlo pequeño y rechazar agregar características es importante para que Zastand sea Zastand. Ser pequeño y no agregar características significa que la implementación actual casi define el comportamiento.

Como dije, la implementación principal está básicamente completa. Eso no significa que no haya errores. Puede haber algunos errores y es posible que cambiemos algo en el futuro. El punto es que no lo cambiamos por más características. Esto nos lleva a una regla básica sobre qué tipo de solicitudes de extracción es probable que se acepten. Agregar pruebas para cubrir el comportamiento actual es bienvenido. Agregar código solo para desarrollo para mejorar la experiencia del desarrollador sería genial. Agregar documentación es muy útil. Los tipos de TypeScript aún pueden tener margen de mejora. Por último, agregar características se hace a través de middleware. Hay algunos middleware en el repositorio de Zastand. Mejorarlos sería bueno, aparte de eso, es poco probable que agreguemos nuevos middleware. Sugerimos a las personas crear bibliotecas de terceros para hacer crecer nuestro ecosistema.

He estado diciendo que Zastand es pequeño, ¿qué tan pequeño es? Veamos su código JavaScript. La captura de pantalla muestra el código de la versión 4.1.3. Son 40 líneas en la versión ESM. Esto no incluye los tipos de TypeScript, algunas funciones de utilidad y middleware. Nuevamente, debería ser bastante fácil crear una biblioteca similar a Zastand desde cero. Probablemente, la parte más única del código de Zastand sea la función setState. Su comportamiento predeterminado es fusionar el objeto de estado para que no anule las funciones de acción definidas en el nivel superior del objeto de estado. Es genial ver que el ecosistema de Zastand está creciendo. Parece haber más de 800 bibliotecas que dependen de Zastand. Hay bastantes bibliotecas de terceros para Zastand y el número sigue creciendo. Como dije anteriormente, no agregamos nuevas características en la biblioteca principal. En cambio, animamos a las personas a desarrollar bibliotecas de terceros.

Espero que más personas se interesen en ello. Ahora, a medida que Zastand se vuelve popular, me he planteado un pequeño desafío. El desafío es cómo monetizar este trabajo. La mayoría del software de código abierto se puede utilizar de forma gratuita, por lo que no hay una razón directa para pagar por su uso. Y eso es bueno, porque puedes probarlo sin ningún riesgo antes de decidir si usarlo o no. Para monetizar el software de código abierto, uno podría pensar en el patrocinio, que es bueno y funciona hasta cierto punto. Además del patrocinio, me di cuenta de que algunos desarrolladores de software de código abierto venden tutoriales, cursos o tal vez libros. Es más significativo pagar por un producto. Me gusta la idea. Este tweet es mi primer intento. Escribí un pequeño fragmento de código para mostrar Zastand simplificado con algunos comentarios de código. No estoy totalmente seguro de si fue exitoso, pero hubo algunas cosas que aprendí. Por ejemplo, las personas estaban más dispuestas a ver videos. El desafío no ha terminado. Todavía estoy tratando de explorar qué productos puedo ofrecer.

Así que eso es todo para la historia de Zastand. Hablemos un poco sobre Jotai, otra biblioteca de gestión de estado que desarrollé, y comparémosla con Zastand. Mientras desarrollaba la versión 3 de Zastand, se me ocurrió otra idea que no era muy compatible con Zastand. Está más orientada a React y con el soporte de concurrencia en mente. Así que decidimos desarrollar Jotai después del lanzamiento de la v3. Uno de los objetivos de Jotai es tener un seguimiento de dependencias que pueda evitar los selectores. Los selectores son necesarios en Zastand para optimizar las actualizaciones de renderizado. Esto hace que el modelo de estado sea muy diferente. Mientras que Zastand tiene una tienda y los selectores crean fragmentos de la tienda, Jotai tiene múltiples estados al principio, y los combinamos para derivar un nuevo estado. Los llamamos átomos.

¿Estarías interesado en comparar Zastand y Jotai? Para explicar cómo son diferentes al desarrollar aplicaciones, tomemos un ejemplo muy simple. Una aplicación de contador. Veremos el código en dos implementaciones. Tiene un componente que muestra un número de conteo y un botón para incrementar el número. Hay otro componente que muestra un número de conteo doble. El conteo doble es un estado derivado que se actualiza automáticamente cuando cambia el conteo original.

La primera implementación es con Zastand. Esta muestra la implementación de Zastand de la aplicación de contador. Hay tres funciones. La primera es para crear una tienda. Es convencional tener acciones en una tienda, así que tenemos una función para incrementar el valor del conteo. La segunda es el componente de contador. Toma el valor del conteo y la función de incremento y muestra un número y un botón. El último es el componente doble. Utiliza una función de selector para crear un valor derivado. Este es el método principal en Zastand para crear estados derivados. Es bastante sencillo y está orientado a hooks. Una trampa con la función de selector es que si crea una nueva referencia, causará un bucle infinito. Y esa es la motivación de Jotai para evitar los selectores.

Continuemos y veamos la implementación con Jotai. Esta es la implementación de Jotai de la aplicación de contador. Primero definimos dos átomos. Uno se llama countAtom, que es un átomo primitivo o fuente de datos. El otro se llama doubleAtom, que es un átomo derivado. El átomo derivado se define con una función. La función se vuelve a evaluar cuando cambian las dependencias. Los dos siguientes componentes deberían resultar familiares. El primero es el componente de contador, cuyo uso es el mismo que el de useState. El segundo es el componente doble, que lee el valor del átomo y lo muestra. Podríamos crear un átomo de acción para la función de incremento como lo hicimos en Zastand.

También podríamos omitir las acciones en Zastand. Así que es más o menos una diferencia en el estilo de programación. Espero que esto ilustre la diferencia básica de los modelos de estado entre Zastand y Jyotai.

Para resumir esta charla, hemos estado desarrollando Zastand durante los últimos años. Zastand es una pequeña biblioteca para proporcionar una tienda para el estado global de React. Es menos dogmática y tiene suposiciones pequeñas. La tienda de Zastand puede tener acciones, pero no mantiene estados derivados. Es para tener una única fuente de verdad.

Desarrollamos Jyotai con el mismo objetivo, pero con un modelo de estado diferente. Los átomos de Jyotai representan piezas de estados. Pueden ser derivados de otros. Las acciones se pueden definir en componentes, hooks y también en átomos. Los átomos son definiciones abstractas de estados. En resumen, Zastand se centra más en la tienda y las acciones, mientras que Jyotai se centra más en la abstracción del estado y el grafo de data. Esta charla abarcó desde la historia de desarrollo de Zastand hasta la comparación con Jyotai. Espero que ayude a comprender las bibliotecas de estado global. Gracias por ver.