Historia del Desarrollo de Zustand

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

Para aquellos que no lo saben, 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 la programación, y especialmente el software de código abierto. Hay muchos trabajos de código abierto que he realizado. La mayoría 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 sobre la cual di una charla anteriormente. Valusio es otra biblioteca más. Todas esas tres se desarrollaron con un equipo llamado Poimanderes. Esa ú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 hooks de React. Pero tengo un interés más amplio en JavaScript en general.

De todos modos, la charla de hoy es sobre Zestand. Zestand es uno de los proyectos exitosos. Es una biblioteca de gestión de estado, y hay tantas bibliotecas de este tipo por ahí. Debido a que hay tantas, hacer que la gente las conozca y se vuelvan populares es un gran desafío. Afortunadamente, Zestand ha llamado algo de atención hasta ahora. Es solo suerte, supongo. 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 han sido para la gestión de estado. Antes de los hooks, había desarrollado una biblioteca con el contexto de React, al igual que otros lo hicieron. Tomé el mismo enfoque y creé una versión con hooks de ella.

Mientras lo desarrollaba, sabía que no requiere el contexto de React porque el caso de uso es el estado global. Los usuarios nunca tendrán componentes proveedores anidados. De hecho, 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. Todavía estaba en bruto, pero consiguió algunos usuarios. Con algunos colaboradores, la versión 1 fue lanzada en junio. Poco después, lo encontré en algún lugar. En ese momento, tenía una herramienta, un repositorio, que es para comparar varias bibliotecas de estado global. Fue construido para verificar el comportamiento del renderizado concurrente. La herramienta se utilizó para verificar mis bibliotecas y algunas otras bibliotecas populares. Así que también añadí Zastand allí. Zastand era único ya que no usaba el contexto de React en absoluto. Todos los demás usaban el contexto para la propagación del estado o el alcance de las tiendas. Creo que el contexto de React ha sido sobreutilizado para el estado global. A menos que uses proveedores de contexto múltiples veces en tu árbol de componentes, no es contextual. El estado global definido a nivel de módulo debería simplemente funcionar. Zastand fue un pionero en este enfoque. Estoy convencido de ello y reimplementé una de mis bibliotecas. Más tarde, escribí un detallado post en el blog sobre ello. De todos modos, así fue como conocí Zastand. Como dije, uno de mis repositorios para comparar varios estados globales en el renderizado concurrente.

Estaba interesado en hacer Zastand más amigable con el renderizado concurrente para el futuro de React. Me uní al equipo en agosto de 2020 y tomé el desarrollo de Zastand. Zastand había sido desarrollado activamente el año anterior y alcanzó la versión 2. Sin embargo, no fue realmente mantenido después de eso. Había una cierta cantidad de usuarios y pocos problemas abiertos, pero nadie se estaba ocupando de ellos. Mientras mi motivación era el renderizado concurrente, comencé a mantenerlo y resolver esos problemas. La v3 fue lanzada el mismo mes que comencé a trabajar en ello. Tuvo dos grandes mejoras, pero aparte de eso, es básicamente compatible con la versión anterior.

La buena noticia es que me familiaricé con la base de código. 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. Hicimos muchos experimentos y duplicamos algunas de las características antiguas. La próxima versión es para el renderizado concurrente, que fue mi motivación original. Para ese momento, React 18 fue lanzado, con un nuevo hook llamado useSyncExternalStore. Hubo una larga historia detrás de eso, pero ese hook es un sucesor de nuestra solución ejecutada por el usuario. Zest y V4 fueron lanzados con ese hook. En realidad, utiliza la biblioteca shim proporcionada por React, para que funcione con React 17. La implementación de la biblioteca está casi reescrita en V4 en comparación con lo que teníamos en V2 antes de que me uniera. Los tipos de TypeScript han mejorado bastante, lo cual fue hecho por un colaborador. Ha sido un gran viaje llegar aquí. Aprendí varias cosas, no solo a programar, sino también a hacer crecer la comunidad. Aprecio a todos los que participaron en este proyecto.

En este momento, el estado de este proyecto es bastante estable. Especialmente, la implementación central 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 futuras versiones una vez que entendamos cómo avanza React. Especialmente, no estamos seguros sobre el hook propuesto use. Aún no es seguro qué vendrá después. Lo que se hará, con seguridad, es eliminar las características duplicadas. Probablemente eliminaremos el shim de useSyncExternalStore. Así que en la próxima versión principal, probablemente eliminaremos el soporte para React 17.

Retrocedamos un poco y hablemos sobre 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 añadir un poco más de requisitos, sigue los principios de Flux, es menos dogmática y aún extensible. Así que 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 añadir varias características encima de él. Mantenerlo pequeño y rechazar añadir características es importante para que Zastand sea Zastand. Ser pequeño y no añadir características significa que la implementación actual casi define el comportamiento.

Como dije, la implementación central está básicamente completa. Eso no significa que no haya errores. Puede haber algunos errores y podríamos cambiar algo en el futuro. El punto es que no lo cambiamos para más características. Eso lleva a una regla básica sobre qué tipo de PRs es probable que se acepten. Añadir pruebas para cubrir el comportamiento actual es bienvenido. Añadir código solo para desarrollo para mejorar la experiencia del desarrollador sería genial. Añadir documentación es muy útil. El tipo de TypeScript aún puede tener margen de mejora. Finalmente, añadir características se hace mediante middleware. Hay algunos middleware en el repositorio de Zastand. Mejorarlos sería bueno, aparte de eso, es poco probable que añadamos nuevos middleware. Sugerimos a las personas crear bibliotecas de terceros para hacer crecer nuestro ecosistema.

Seguí 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 compilación ESM. Esto no incluye los tipos de TypeScript, algunas funciones utilitarias y middleware. Nuevamente, debería ser bastante fácil crear una biblioteca similar a Zastand desde cero. Probablemente la parte más única en el código de Zastand es la función setState. Su comportamiento predeterminado es fusionar el objeto de estado para que no sobrescriba 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 que hay 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 añadimos nuevas características en la biblioteca central. En cambio, alentamos 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, tengo un pequeño desafío para mí. El desafío es cómo monetizar este trabajo. La mayoría del OSS puede usarse libremente, por lo que no hay una razón directa para pagar por usarlo. Y es bueno, porque puedes probarlo sin ningún riesgo antes de decidir si usarlo o no. Para monetizar OSS, uno podría pensar en el patrocinio, lo cual es bueno y funciona hasta cierto punto. Aparte del patrocinio, noté que algunos desarrolladores de OSS venden tutoriales, cursos o quizás 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, la gente estaba más dispuesta a ver videos. El desafío no ha terminado. Todavía estoy tratando de explorar qué productos puedo ofrecer.

Hasta aquí la historia de Zastand. Hablemos un poco sobre Jotai, otra gestión de estado que desarrollé y compáremosla con Zastand. Mientras desarrollaba la versión 3 de Zastand, tuve otra idea que no es muy compatible con Zastand. Está más orientada a React y con 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 seguimiento de dependencias que pueda evitar los selectores. Los selectores son necesarios en Zastand para optimizar las re-renderizaciones. Esto hace que el modelo de estado sea muy diferente. Mientras que Zastand tiene una tienda y los selectores crean porciones de la tienda, Jotai tiene múltiples estados al principio, y los combinamos para derivar un nuevo estado. Los llamamos átomos.

¿Te interesaría comparar Zastand y Jotai? Para explicar cómo estos dos son diferentes cuando desarrollas 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 cuenta y un botón para incrementar el número. Hay otro componente que muestra un número de cuenta doble. El doble de la cuenta es un estado derivado que se actualiza automáticamente cuando cambia la cuenta original.

La primera implementación es con Zastand. Esto muestra la implementación de Zastand de la aplicación de contador. Hay tres funciones. La primera es para crear una store. Es convencional tener acciones en una store, así que tenemos una función para incrementar el valor de la cuenta. La segunda es el componente de contador. Toma el valor de la cuenta y la función ink y renderiza un número y un botón. La última 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. Un inconveniente con la función de selector es que si crea una nueva referencia, causará un bucle infinito. Y esa es la motivación para que Jotai evite los selectores.

Pasemos a ver 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 reevalúa cuando cambian las dependencias. Los siguientes dos componentes deberían parecer familiares. El primero es el componente de contador, cuyo uso es el mismo que use state. El segundo es el componente duplicado, 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.

Podríamos omitir acciones en Zastand también. Así que es más o menos una diferencia en el estilo de programación. Espero que esto ilustre la diferencia básica de 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 store para el estado global para React. Es menos opinada y tiene pequeñas suposiciones. La store de Zastand puede tener acciones, pero no mantiene estados derivados. Es para una única fuente de verdad.

Desarrollamos Jyotai para el mismo objetivo, pero con un modelo de estado diferente. Los átomos de Jyotai representan piezas de estados. Pueden derivarse de otros. Las acciones pueden definirse en componentes, hooks, y también en átomos. Los átomos son definiciones abstractas de estados. En resumen, Zastand está más enfocado en store y acciones mientras que Jyotai está más enfocado en la abstracción del estado y el gráfico de datos. Esta charla cubrió desde la historia del desarrollo de Zastand hasta la comparación con Jyotai. Espero que ayude a entender las bibliotecas de estado global.