El Futuro Visual de la Gestión de Estado

Ahora, ¿qué queremos decir con visual? Probablemente sepas qué es un diagrama de Venn. Es una representación visual exacta de las similitudes entre dos o más cosas diferentes. Y es posible que también hayas oído hablar de un diagrama de secuencia. Este describe cómo diferentes partes de un sistema se comunican entre sí. Ahora, diagramas como estos son muy útiles para transmitir relaciones de una manera visualmente inequívoca, cada uno con sus propias notaciones especiales que significan cosas específicas. Y las máquinas de estado y los diagramas de estado, de los que hablo mucho, caen en la misma categoría de diagrama visualmente exacto en el sentido de que describen la lógica y el comportamiento de una entidad especial utilizando una notación especial como flechas, cajas y regiones.

Ahora, David Harold, el inventor de los diagramas de estado, llama a esto un formalismo visual. Describe que los formalismos visuales son lenguajes diagramáticos e intuitivos, pero rigurosos matemáticamente y precisos. Por lo tanto, a pesar de su apariencia visual clara, vienen completos con una sintaxis que te permite determinar qué está permitido y qué no está permitido. Y también vienen con una semántica que determina qué significan realmente las cosas permitidas. Estos tipos de visualizaciones sirven a un propósito más elevado que simplemente hacer que tu aburrida documentación se vea un poco mejor. Sirven como una especificación exacta de algo que sería difícil de describir solo con texto.

Entonces, la forma en que típicamente codificamos la lógica de la aplicación no se presta realmente bien a un formalismo visual o a cualquier otra cosa realmente. Tendemos a colocar datos y lógica cerca de la fuente donde se utiliza, como directamente en los controladores de eventos o en promesas o en devoluciones de llamada o cosas así. Si bien esto puede ser conveniente para codificar, el problema es que esta lógica es difícil de entender, especialmente a medida que cambia con el tiempo debido a eventos o cualquier otra cosa que pueda suceder. Y realmente no puedes discernir qué puede suceder exactamente o cómo puede responder una aplicación a un evento en cualquier momento. Esa lógica de conexión, reside principalmente en la cabeza del desarrollador que codificó esa lógica, lo cual no es realmente útil. Y peor aún, con lógica ad hoc, que tiende a repetirse en todo el código base. Incluso si intentas elevar esto, tienes esa misma lógica ad hoc viviendo en otro lugar en lugar de un lugar centralizado donde vive toda tu lógica.

Entonces entra el reductor. Por supuesto, el reductor se popularizó muy temprano por bloques y bibliotecas de gestión de estado como Redux. Y los reductores son los que se utilizaban para proporcionar una forma de contener toda esta lógica en una ubicación centralizada y conveniente. Por lo tanto, una restricción importante y enormemente beneficiosa del reductor es que te obliga a interactuar con la lógica mediante el envío de eventos o acciones, como se les llama en el mundo de React y Redux. Por cierto, el nombre de las acciones, no me gusta particularmente, creo que fue un error. Vamos a usar el término eventos en lugar de acciones en esta presentación. Pero aquí está por qué el envío de eventos es algo realmente bueno.

Te obliga a concretar lo que puede suceder en tu aplicación en cualquier momento. Por ejemplo, el usuario puede hacer clic en un botón, una solicitud puede resolverse o rechazarse, o un temporizador puede activarse. Todos estos son eventos. Pensar en tu aplicación en términos de eventos simplifica realmente el modelo mental. Sin embargo, esto tampoco es fácil de visualizar. Los reductores típicamente contienen declaraciones switch o if para discernir qué debe suceder cuando se recibe un evento. Por lo tanto, comprender cómo puede cambiar el comportamiento de tu aplicación se vuelve mucho más difícil. Se mezcla en esas declaraciones switch y tienes que reconstruir toda esa lógica y navegar a través de un montón de declaraciones defensivas como ternarios e if para dar sentido a la lógica.

Es como si tu reductor fuera una única declaración en una máquina de estado con un único estado en un montón de transiciones condicionales y a veces innecesarias. Puede funcionar y puede hacer el trabajo que se supone que debe hacer, pero es difícil de entender y aún es propenso a estados y transiciones imposibles. Las máquinas de estado, por cierto, son como reductores y hablo de esto prácticamente en todas partes en línea, y las máquinas de estado también se pueden escribir como reductores, pero en lugar de mezclar toda la lógica, separan de manera clara los comportamientos en lo que se conocen como estados finitos. Un estado finito representa un comportamiento. Cuáles son los estados actuales de un actor y cómo podría responder a eventos. Puede responder a eventos realizando una acción o cambiando su comportamiento, lo cual está representado por las flechas de transición que ves aquí, que van de un estado a otro. O los eventos pueden no ser manejados, en cuyo caso el comportamiento predeterminado es ignorar los eventos. En los reductores, esto a menudo requiere mucho código defensivo como declaraciones if. En las máquinas de estado, esto está integrado en el modelo matemático. Y más prácticamente, este tipo de mecanismo evita estados imposibles, lo que garantiza que dos comportamientos no puedan ocurrir al mismo tiempo. También evita transiciones imposibles, ya que todas las transiciones entre estados finitos deben escribirse explícitamente. Y como puedes ver aquí, se presta bien a la visualización. Podemos entender cómo un actor puede cambiar su comportamiento reproduciendo los eventos en el diagrama, siguiendo las flechas y viendo cuáles deberían ser los siguientes estados finitos.

Ahora, los diagramas de estado llevan esta misma idea de un formalismo visual introducido por las máquinas de estado y la llevan un paso más allá. Introducen jerarquía, entre muchas otras cosas. Por lo tanto, aunque las máquinas de estado proporcionan una forma de organizar de manera clara la lógica, sufren de una explosión combinatoria de estados y transiciones, especialmente cuando diferentes estados finitos están relacionados. Al extender la noción de máquinas de estado para que sea un grafo jerárquico o un grafo alto, como lo llama David Harrell, podemos agrupar estados juntos para representar transiciones comunes de manera clara. También podemos aislar la lógica para ver el panorama general en lugar de tener que entender todos los pequeños detalles de implementación de una vez en una estructura plana grande. Al igual que las máquinas de estado, los diagramas de estado también son formalismos visuales matemáticamente rigurosos. Pueden expresar un grado mucho mayor de complejidad que las máquinas de estado y pueden representarlo de manera clara y visual. Por eso creé XState hace algunos años.

Y XState, por cierto, es una biblioteca de máquinas de estado y diagramas de estado para JavaScript. Es independiente del framework y eventualmente independiente de la plataforma. Básicamente, quería que los desarrolladores pudieran representar máquinas de estado y diagramas de estado de una manera que pudiera ser codificada de forma limpia y también visualizada automáticamente, razón por la cual tiene una notación similar a JSON. A diferencia de tu típico reductor, XState se enfoca en el estado primero, no en los eventos primero. Te obliga a centrarte en separar tus comportamientos en términos de estados finitos y luego especificar las transiciones basadas en eventos. Puedes hacer esto sin XState, pero implicaría hacer cosas como anidar declaraciones switch y, por supuesto, no sería fácilmente visualizable. Como mencioné, la máquina en sí puede tener su función de transición representada como un reductor. Es una función pura. Y esto te permite llevarlo a cualquier lugar, ya sea React u otro lugar, y también incluye una forma de especificar declarativamente efectos secundarios o acciones que se pueden ejecutar. Pero XState también incluye utilidades para interpretar la máquina como un servicio único donde puedes enviar eventos de forma imperativa. El estado del servicio se mantiene interno. Por lo tanto, puedes usarlo básicamente como un emisor de eventos y también es observable. Funciona con bibliotecas como RxJS. Por supuesto, también puedes usar esto en React, que es uno de los frameworks más populares. La forma en que lo usarías es de la misma manera que usarías useReducer. Eso es muchas formas de uso. Entonces, tomarías el hook useMachine de XState React, colocarías tu máquina de estado directamente allí. Y nuevamente, estamos pensando en una máquina de estado como un reductor sofisticado en este contexto. Luego, XState React proporciona una serie de utilidades que te ayudan a usar ese estado y orquestar las vistas de tu aplicación en función de eso, como state.matches. Y, por supuesto, al igual que useReducer, también puedes enviar eventos directamente a la máquina que afectarán el estado. Pero hoy quiero hablar sobre algunas características recientes y próximas de XState. En primer lugar, en XState React, hay un par de nuevos hooks, como useInterpret, que simplemente devuelve el servicio. Y puedes pasar eso a través del contexto y veremos por qué querrías hacer eso aquí. Cuando extraes ese contexto en algún componente, ese servicio se puede usar prácticamente en cualquier lugar. Es muy similar a Redux en el sentido de que tienes ese estado y una forma de comunicarte con esa máquina de estado interpretada desde cualquier lugar de tu aplicación. Ahora, por supuesto, esto puede llevar a muchas re-renderizaciones. Ya sabes, tienes el típico problema de contexto donde una actualización de estado en algún lugar puede no ser algo que te importe en un cierto componente, y ahí es donde entra en juego el hook uSelector. Con uSelector, puedes decirle que solo te importa este dato específico y el componente solo se volverá a renderizar cuando ese dato cambie. Pero hablemos de más características nuevas en XState en sí, lo cual me emociona bastante. La primera es create model.

Otro cambio reciente son las etiquetas. Con las etiquetas, podemos asignar algunos estados finitos y etiquetas, que podrías pensar como nombres de clase en HTML y CSS, y podríamos decir que todas estas fechas tienen un.... Entonces, básicamente, esto debería ser 'loading' en lugar de 'pending', pero podríamos decir básicamente que cuando estamos en uno de los estados finitos que tiene esta etiqueta, hacer algo como mostrar un spinner de carga o algo así. Y esto hace que sea muy fácil reutilizar las máquinas de estado en una variedad de contextos diferentes.

Ahora, en la versión cinco de XState, también hay muchas cosas nuevas que vienen. Y estamos trabajando arduamente para lanzar esta versión beta. Una de las cosas interesantes son los comodines parciales. Ahora puedes especificar eventos que, por ejemplo, 'mouse.star' representaría eventos como 'mouse.click', 'mouse.move.out' y otros. Por lo tanto, puedes especificar eventos parciales y capturar transiciones para esos eventos. También puedes especificar guardias de nivel superior. Y, como recordatorio, las guardias son las que hacen que se tomen o no se tomen transiciones. Son básicamente una transición condicional. Y ahora, con las guardias de nivel superior, tenemos una forma de combinar diferentes predicados en una sola transición. Y esto también se presta muy bien a la visualización. En el futuro, verás estas guardias visualizadas como un árbol de decisiones, lo cual es bastante interesante.

Hay muchas otras cosas que vienen en X-State v5. En primer lugar, estamos simplificando todo el modelo de actores detrás de él, donde todo es un actor en lugar de casos especiales, promesas, observables, devoluciones de llamada, cosas así. Solo tenemos una interfaz unificada que si es un actor, si es algo a lo que puedes enviar eventos y recibir eventos de, entonces X-State funcionará naturalmente con él. Y esto abre muchas posibilidades en el futuro con la integración con otros frameworks y otras bibliotecas también. Además, en el método 'assign', esto fue un error que técnicamente rompe en la v4, pero se corregirá en la v5 para que cuando realices llamadas 'assign', se realicen en el orden en que se especificaron en lugar de al principio. También estamos trabajando arduamente en la tipificación de TypeScript para tipificar de manera sólida acciones, servicios, guardias y más, así como claves de estado y cosas así. Básicamente, estamos haciendo que esta sea una experiencia de tipificación lo mejor posible para el desarrollador. Hablando de la experiencia del desarrollador, también estamos trabajando en hacerlo modular y más pequeño para que solo necesites importar las cosas que te interesan. A menudo se ha dicho que XState tiene muchas características y es posible que no necesites todas esas características. Y así, si quieres mantener el tamaño del paquete bajo, puedes importar solo las cosas que necesitas de XState en lugar de todo. Y, por supuesto, esta es solo una lista corta de muchas más mejoras que vendrán en la versión cinco. Siempre estamos abiertos a tus sugerencias sobre cómo podemos mejorar XState. Pero sí, todo esto es para decir que XState no es solo una biblioteca de gestión de estado.

Tiene muchas metas que van mucho más allá del simple propósito de la gestión de estado. Por un lado, la visualización. Queremos hacer que todo lo que crees en XState se pueda visualizar automáticamente en tiempo real, y te lo mostraré en la próxima diapositiva. También las pruebas. Tenemos XState Test y también queremos que sea capaz de generar pruebas automáticamente y usarlas con tus suites de pruebas de extremo a extremo, y hacer que sea una experiencia de pruebas mucho mejor para que no tengas que escribir manualmente todas tus pruebas. También el análisis. XState, ya que no es solo una caja negra, es un grafo dirigido donde puedes conocer todas las transiciones de estado que pueden ocurrir. Podemos registrar análisis y ver exactamente qué sucede en tu aplicación a medida que un usuario la recorre. Por supuesto, esta sería una herramienta opcional, pero es algo en lo que estamos trabajando, y también la generación automática. Nuevamente, debido a que tenemos esa máquina de estado y el gráfico dirigido descrito como un grafo dirigido, podemos hacer cosas realmente divertidas como generar automáticamente pruebas, documentación, diagramas e incluso otros formatos.

Ahora, XState Inspect es un ejemplo de esto. Lo lancé hace unos meses, pero XState Inspect es una utilidad que te permite visualizar máquinas de estado en cualquier framework en tiempo real. En este ejemplo, es un temporizador con el que estamos interactuando, y puedes ver la máquina de estado en la parte inferior que cambia a medida que hacemos clic. Y esto funciona en ambas direcciones. Entonces, si haces clic aquí o envías cualquier evento a través del inspector, también afectará a la aplicación. Y eso es un pequeño vistazo al futuro de las herramientas de XState. Esto también se ha utilizado en el recientemente anunciado xstatecatalog.com por Matt Pocock, que es un catálogo impresionante de muchos ejemplos útiles de máquinas de estado que puedes copiar y pegar directamente en tu aplicación. E incluso puedes interactuar con la documentación aquí y ver cómo cambia el diagrama visual a la izquierda, lo cual es realmente genial. Así que te animo a que visites xstatecatalog.com.

Pero en general, el estado actual de las cosas y una de las razones más importantes por las que creé XState fue porque es difícil entender cómo funciona tu código. Y cuanto más características y código agregamos, más errores y más casos límite introducimos involuntariamente en nuestras aplicaciones, lo que significa que necesitamos más pruebas para una cobertura completa y necesitamos más esfuerzo de desarrollo, lo que cuesta tiempo y dinero. Ahora, la documentación ayuda, pero rápidamente se vuelve obsoleta y a menudo no describe el sistema a un nivel más alto. Los diagramas también son útiles para esto, pero son tediosos de crear y también se vuelven obsoletos rápidamente. Y generar diagramas a partir del código es una gran solución para esto, pero creo que podemos hacerlo aún mejor porque creo que el futuro son los diagramas ejecutables, que son diagramas que no solo se generan a partir del código, sino que también se pueden convertir en código y editar visualmente. Y esto abre la posibilidad de colaborar con personas menos técnicas como diseñadores y jefes de proyecto, al tiempo que permite a los desarrolladores comprender rápidamente cómo funciona la lógica en todos los niveles del stack sin preocuparse por la documentación obsoleta. Y por eso estoy muy emocionado de anunciar Stately, que será una futura suite de modelado de software visual para crear, editar, simular, analizar, probar y colaborar en la lógica y los flujos de trabajo de la aplicación para cualquier lenguaje en el futuro. Así que llevamos XState y sus herramientas al siguiente nivel para hacer que tu código haga más. Te animo a que visites stately.ai y te suscribas a la lista de correo para ser el primero en saber cuándo se lance la versión beta. Y con eso, gracias por ver JS Nation. Gracias, David, por compartir tu conocimiento y experiencia en la gestión de estado.

Entonces, ¿qué piensas de estos resultados, David? Y bienvenido a nuestro estudio. Gracias, creo que son sorprendentes pero no demasiado sorprendentes porque si hubieras hecho esta pregunta hace un año o tres años, la mayoría de las personas habrían respondido que no o aún no. Y lo habrían dicho porque las máquinas de estado tradicionalmente han sido un tema muy, supongo que podrías decir, un tema académico, no es un tema que sea realmente prevalente en el desarrollo de software, a menos que hayas estudiado cosas como UML o electrónica embebida, o simplemente patrones formales y cosas así. Pero ahora estamos viendo que cada vez más personas están entendiendo el valor de usar máquinas de estado y gráficos de estado para modelar el estado de sus aplicaciones. Así que es realmente alentador que muchas personas estén utilizando máquinas de estado en sus aplicaciones ahora.

Sí, sí, sí, bastante justo. Y creo que había un truco en tu pregunta porque no presté demasiada atención a la redacción exacta y vi algo, oh, algo sobre estado. Sí, por supuesto que uso una biblioteca de estado, pero no se trataba solo de una biblioteca de estado genérica. Se trataba de una máquina de estado. Y sí, personalmente no la he usado en mi proyecto. Así que tal vez después de tu sesión, definitivamente lo intentaré. Bueno, veamos qué quieren preguntarte nuestros queridos asistentes. Sí, mantengamos la pregunta sobre el futuro para el futuro. Tenemos suficiente tiempo para hacer esto. Muy, muy práctico. ¿Cómo se ve la testing en el mundo de XState? Bueno, la testing se ve genial. Y hay dos aspectos en esta pregunta. Primero está testing las máquinas de estado en XState en sí. Las máquinas de estado, como mostré, tienen una función de transición. Estas son funciones puras, lo que significa que si quieres probar que después de que un usuario realice X número de eventos, termine en un estado determinado, simplemente puedes hacer eso. Puedes enviar los eventos a esta función de transición pura de la máquina y simplemente afirmar que está en los estados que esperas que esté. Y no solo eso, puedes hacer cosas como state.matches o con la nueva etiqueta, puedes hacer state.hasTag y asegurarte de que no solo obtienes los estados correctos sino también que se disparan los eventos correctos. Y en el otro lado de esto, hay una biblioteca, una biblioteca complementaria, para Xstate llamada Xstate-test, y eso te permite hacer mucho más que solo testing tus máquinas de estado. Puedes probar aplicaciones completas incluso si no están escritas con máquinas de estado en absoluto, y no importa en qué framework estén. Lo que haces es describir tu modelo como una máquina de estado, o como el modelo de la aplicación, y lo modelas como una máquina de estado, y lo ejecutas a través de Xstate-test, que va a generar automáticamente todas las formas posibles en las que el usuario podría recorrer la aplicación y asegurarse de que se alcancen todos los estados esperados.

Entonces, es como hacer pruebas de extremo a extremo, pero a un nivel mucho más grande. También quería mencionar algo sobre las pruebas. Debido a la forma en que Xstate te permite especificar acciones, guardias, servicios, etc., como una cosa secundaria, podrías simular fácilmente cualquier efecto secundario allí. Es como tener la inyección de dependencias incorporada en Xstate. Los efectos son ciudadanos de primera clase, por lo que también puedes probar los efectos. Sí, las pruebas son geniales en Xstate.

Sí, bastante justo. Entonces, para resumir tu pregunta, no hay excusa para que nosotros, los desarrolladores, ignoremos las pruebas en Xstate y otras bibliotecas de máquinas de estado, porque las herramientas están ahí, simplemente debemos usarlas. Y por lo que entendí, la experiencia del desarrollador es bastante buena cuando se utiliza esta herramienta.

De acuerdo. Permíteme elegir la siguiente pregunta. Sí, vamos a elegir esta. ¿Cuál es la curva de aprendizaje para usar Xstate si tienes experiencia, por ejemplo, en Redux? Sí, si tienes experiencia en Redux, entonces la curva de aprendizaje para Xstate es realmente muy baja. De hecho, con una de las actualizaciones más recientes, hemos agregado soporte para lo que se llaman máquinas combinatorias. No me gusta el nombre, es solo un nombre que era el nombre oficial de Wikipedia. Pero lo que significa es una máquina de estado que solo tiene un estado. Por lo tanto, convertir un reductor en una máquina de estado ahora es tan fácil como, en lugar de poner todo en grandes declaraciones switch, lo pones en un objeto. Básicamente, estás convirtiendo switch en objeto, lo que significa que escribes mucho menos código y puedes hacer cosas como gestionar efectos secundarios directamente allí. Incluso puedes refactorizar cosas desde Redux. Pero esto hace que la migración a Xstate sea mucho más fácil. Entonces, sí, lo mismo con Redux, si estás usando algo como Redux, Vuex, Ngrx con esa arquitectura basada en acciones, entonces Xstate será una opción muy natural porque todo depende de los eventos como mecanismo de comunicación. Así que sí, recomiendo que si conoces esas bibliotecas, no temas a Xstate porque la curva de aprendizaje no es tan mala. Ya casi estás en la cima de esa curva de aprendizaje.

Wow, eso suena genial. Suena muy prometedor. Realmente creo que ayudar a las personas a adoptar una nueva tecnología es clave para el éxito de esa tecnología. Así que eso es realmente genial. Tomemos la siguiente pregunta y sí, vamos con esta con muchos detalles. Entonces, la pregunta es que nuestras aplicaciones tienen alrededor de 100,000 líneas de código de lógica compleja de NGRX y dicho gráfico generado automáticamente sería un tesoro.

¿Crees que utilizar Xstate en cierta medida en combinación con NGRX solo para la visualización es una buena idea o tienes algún consejo sobre cómo componer Xstate o Stately con NGRX para la visualización? Sí, la pregunta de cómo pasar de NGRX a Xstate y utilizarlo para la visualización es una pregunta muy interesante porque en teoría se puede hacer porque con Xstate se puede utilizar la función machine.transition con prácticamente cualquier biblioteca de gestión de estado que ya tengas. Y eso es algo en lo que nos vamos a centrar mucho en el futuro también, que es trabajar con NGRX, UX, Redux, todas estas bibliotecas de gestión existentes. Pero en teoría, sí, es posible simplemente utilizar esa función de transición, ponerla en NGRX y poder visualizar la lógica de tu aplicación directamente desde allí. En resumen, todavía estamos experimentando con eso. Sabemos que migrar cien mil líneas de código a Xstate es una tarea no trivial. Así que nuestro objetivo es facilitar eso al máximo. Increíble. Increíble. Sí. Grandes planes.

Así que eso es interesante. Pasamos por Redux, que creo que es más una cosa de React. Pasamos por NGRX, que es una cosa de Angular. Y no pudimos encontrar mejores atajos para la siguiente pregunta, que es, ¿puedes usar X state entre frameworks y mantener la funcionalidad? Sí, absolutamente puedes. Y de hecho, esta es una de mis características favoritas de usar X state y state charts. Tengo una demostración, intentaré encontrar los enlaces y los pondré en spatial.chat después. Pero recreé el temporizador de un teléfono Android y en realidad se ve así. Podría mostrarte como si tuvieras un pequeño cronómetro y reproducirlo. Así que esto, lo recreé en REACTS utilizando X states y la máquina de estado para ese temporizador. Y quería ver qué tan rápido podía migrar eso o no migrar, sino usar esa lógica y recrear ese temporizador en Vue. Y me llevó solo 10 minutos. Y la mayoría de esos 10 minutos fueron solo para encontrar cómo usar los íconos de Font Awesome en la aplicación de Vue solo porque no soy tan bueno en Vue. Pero sí, uso la misma máquina exacta. Así que es extremadamente flexible. Puedes usar la misma máquina en cualquier framework o incluso sin ningún framework. Eso es realmente genial. Y esto es como un punto de unidad muy natural para las personas que desarrollan utilizando diferentes frameworks. Sí, ya sea que estés en Angular o REACT o Svelte o Vue. X state es como un punto de conexión en estos equipos de desarrollo.

Bueno, antes de pasar a la siguiente pregunta seria, vamos a responder a esta. Alguien es un gran fan de tu camiseta que tenías durante el video, es genial, ¿cómo puedo conseguirla? Bueno, en realidad, creo que todavía la hacemos. Así que hago un stream con uno de mis amigos, Steven Shaw, en los key framers. De hecho, esta camiseta dice key framers aquí. Así que esta es otra de nuestras camisetas. Si vas a keyframe.rs, creo que también hay un enlace allí. Es un stream en vivo semanal donde básicamente damos vida a interfaces de usuario imaginativas utilizando HTML, CSS y JavaScript. Y hoy, en realidad, en unas pocas horas, vamos a hacer una demostración de X state, creando un simple juego de tres en raya utilizando X state en CodePen. Así que no te lo pierdas. ¡Guau, eso es genial! Así que gente, vayan a escuchar este evento y consigan su camiseta.

Ahora nos quedan dos minutos y la pregunta es la que quería tomar desde el principio. ¿Cuál es el futuro de X state? Bueno, desde que dejé mi trabajo en Microsoft, ahora estoy trabajando a tiempo completo en X state y herramientas relacionadas. Así que estamos trabajando muy duro en la versión cinco. También estamos trabajando en actualizar el visualizador, que llegará pronto. Y estoy muy emocionado por eso porque el visualizador actual se ejecuta en una versión antigua de X state. Así que realmente queremos actualizarlo y hacer que puedas visualizar múltiples máquinas y también tener el editor Monaco de VS Code. Y en el futuro, queremos crear un editor de arrastrar y soltar, un registro para que cualquiera pueda compartir y colaborar en máquinas que creen visualmente y usarlas directamente en sus proyectos. Así que hay muchas cosas que tenemos planeadas. Y si te suscribes al boletín en stately.ai, serás el primero en enterarte. Muchas gracias, David, por compartir tu sesión, por compartir tus respuestas y por compartir el futuro de la gestión de estados. Nos vemos pronto. Adiós. Gracias por tenerme aquí. Adiós.