XState: el futuro visual de la gestión de estados

Hola a todos. Mi nombre es David Courchide. En línea en Twitter, GitHub, lo que sea, me conocen como David K. Piano. Y hoy quiero hablarles sobre el futuro visual de la gestión de estado y cómo XState va a hacer realidad esa visión futura.

Entonces, hablando de visuales, probablemente sepan lo que es un diagrama de Venn. Es una forma visual y exacta de representar las similitudes entre dos o más cosas diferentes. Y también es posible que hayan usado un diagrama de secuencia antes para describir cómo las diferentes partes de un sistema se comunican entre sí. Entonces, también existen las máquinas de estado y los gráficos de estado, por supuesto, de los que he estado hablando durante un tiempo.

Y las máquinas de estado y los gráficos de estado caen en esta categoría de diagramas visualmente exactos. Porque diagramas como estos son realmente útiles para transmitir relaciones de una manera visualmente inequívoca, y cada uno tiene sus propias notaciones especiales para denotar cosas específicas. Y entonces, con los gráficos de estado, tenemos el mismo tipo de cosa. Tenemos flechas y cajas que describen cómo los estados y la lógica pueden fluir con el tiempo. David Harrell, quien es el inventor de los gráficos de estado, llama a esto un formalismo visual. Y así, él describe que los formalismos visuales son diagramáticos e intuitivos, pero a la vez lenguajes matemáticamente rigurosos. Por lo tanto, a pesar de su clara apariencia visual, vienen completos con una sintaxis que determina lo que está permitido y la semántica que determina lo que pueden ser las cosas permitidas. Y entonces, recomiendo leer su artículo sobre formalismos visuales para obtener más información sobre esta idea realmente, realmente interesante de básicamente estos diagramas que son matemáticamente rigurosos y también ejecutables.

Entonces, la forma en que normalmente code la lógica de la aplicación, ya sea en React o en cualquier otra cosa, realmente no se presta a un formalismo visual o a cualquier otra cosa. Tendemos a co-ubicar data y lógica cerca de la fuente donde se utiliza, como en los manejadores de eventos o a veces en los hooks personalizados de React si queremos un poco más de organización.

Entonces, aunque esto puede ser conveniente para code, el problema es que la lógica es difícil de entender, especialmente a medida que cambia con el tiempo debido a eventos o cualquier cosa que pueda suceder dentro de la aplicación. El problema es que no puedes discernir qué puede suceder o cómo una aplicación puede responder a cualquier evento o señal en cualquier momento. Y entonces, esa lógica de conexión reside en la cabeza del desarrollador que añadió la lógica, lo cual realmente no es útil, y así terminas con cosas como lógica ad hoc también, ya sabes, que obviamente debería ser secada.

Pero el problema es que cuando añades esa lógica ad hoc, la lógica, cuando la secas, podrías ponerla en una función o algo así, y esa función puede terminar, ya sabes, siendo ella misma lógica ad hoc, simplemente viviendo en otro lugar. Así que todavía no estás centralizando todo, lo cual, ya sabes, definitivamente se convierte en un poco de un problema.

Y entonces entra el reductor, popularizado por Flux y las bibliotecas de gestión de estado como Redux, los reductores proporcionan una forma de contener esta lógica en un lugar centralizado y conveniente. Así que una restricción enormemente beneficiosa de los reductores es que te obliga a interactuar con la lógica enviando eventos o acciones, como se les llama en React y Redux. Por cierto, la denominación de acciones fue algo así como un error, al menos en mi opinión. Así que vamos a utilizar el término eventos en esta presentación. Pero aquí está por qué despachar eventos es realmente algo bueno. Te obliga a reificar lo que puede suceder en tu aplicación en cualquier momento dado. Así que el usuario puede hacer clic en un botón, una búsqueda puede resolver o rechazar, un temporizador puede apagarse. Todos esos son eventos. Y pensar en tu aplicación en términos de estado y eventos realmente simplifica el modelo mental, al menos en mi opinión.

Sin embargo, esto tampoco se visualiza fácilmente. Los reductores normalmente contienen declaraciones de cambio o declaraciones de si para discernir qué debería suceder cuando se recibe un evento, distinguiendo así cómo puede cambiar el comportamiento de tu aplicación. Y esto se vuelve mucho más difícil. Mezcla esas declaraciones de cambio y esas declaraciones de si. Y entonces tienes que juntar la lógica navegando a través de un montón de estas declaraciones y lógica defensiva sólo para discernir cuál puede ser el comportamiento de tu aplicación en cualquier momento dado en el tiempo. Todo está en una sola función. Y es difícil de desmontar.

Así que las máquinas de estado son como los reductores. E incluso pueden ser escritas como reductores. Pero en lugar de mezclar toda la lógica, separa limpiamente los comportamientos en lo que se conoce como estados finitos. Un estado finito representa un comportamiento, que es cuál es el estado actual de algún actor y cómo puede responder a los eventos. Así que podría responder a un evento realizando una acción o cambiando su comportamiento o cualquier cosa así. Y eso está representado por estas flechas de transición que van de estado a estado. O un evento podría no ser manejado, en cuyo caso el comportamiento por defecto es ignorar ese evento.

En los reductores, esto a menudo requiere mucho code defensivo, pero con las máquinas de estado, está incorporado directamente en el modelo matemático. Y más prácticamente, este tipo de separación evita estados imposibles, que garantizan que dos comportamientos no pueden ocurrir al mismo tiempo, e imposibles transiciones, ya que todas las transiciones necesitan ser explícitas y sabes, no puedes tener ninguna transición implícita.

Los gráficos de estado llevan esta idea de un formalismo visual un paso más allá al introducir jerarquía. Aunque las máquinas de estado proporcionan una forma de organizar la lógica de manera limpia, sufren de una explosión combinatoria de estados y transiciones, especialmente cuando diferentes estados finitos están realmente relacionados. Al extender la noción de máquinas de estado para ser un gráfico jerárquico, o un HIGRAPH como lo llama David Harrel, podemos agrupar estados juntos y representar transiciones comunes de manera limpia. También podemos aislar la lógica para que podamos ver la imagen más grande en lugar de tener que entender todos los pequeños detalles de implementación en una gran estructura plana. Al igual que las máquinas de estado, los gráficos de estado también son matemáticamente rigurosos, pero pueden expresar una lógica mucho más compleja de lo que puede una máquina de estado, y resuelve el problema de la explosión combinatoria dentro de las máquinas de estado, porque te permite agrupar comportamientos relacionados juntos.

Así que eso es un gráfico de estado. Y por eso es por lo que creé Xstate hace unos años. Quería que los desarrolladores pudieran representar máquinas de estado y gráficos de estado de una manera que pudiera ser codificada de manera limpia, y también pudiera ser visualizada automáticamente, por eso tiene esta notación de objeto similar a JSON. Así que a diferencia de tu reductor típico, Xstate es primero estado, no primero eventos. Te obliga a centrarte en separar tu comportamiento en términos de estados finitos y luego especificar las transiciones basadas en eventos. Puedes hacer esto sin Xstate o cualquier biblioteca, para el caso, pero implicaría cosas como declaraciones switch anidadas, y no sería fácilmente visualizable.

Como mencioné anteriormente, una máquina puede representarse como un reductor, y eso es lo que esta función machine.transition es. Proporcionas el estado actual y los eventos que acaban de suceder, y obtienes el siguiente estado. Lo que también podría hacer es proporcionar una especie de interfaz de emisor de eventos en la que contiene el estado en sí y podrías enviarle eventos y hacer que gestione su propio estado. Esto es realmente útil en situaciones en las que no quieres tener que conectar juntos dónde almacenar el estado. Además de eso, también es observable. Podrías usar esto con RXJS también.

No hace falta decirlo, pero esto es completamente agnóstico al framework. Podrías usarlo con cualquier framework. Está configurado para que sea fácilmente integrable, cualquiera que sea la palabra. Podrías usar cualquier framework como React, Vue, Angular, Svelte, y más. Pero hablando de React, hay muchas utilidades útiles que te permiten usar más fácilmente las máquinas X state con React. Así que una de estas es el hook use machine, y esto es justo como el hook use reducer. De hecho, si conoces use reducer, entonces básicamente ya conoces use machine. Así que en lugar de pasar un reductor, pasarías una máquina que has creado, y obtienes los mismos dos valores esperados de la tupla, el estado, que representa el estado actual de la máquina, y send, que representa una forma de enviar eventos a esa máquina en ejecución. Ahora, el estado también tiene algunas utilidades, como matches, de modo que en lugar de tener que averiguar cuál es el estado finito exacto de la máquina, podrías simplemente pasar, como, los estados esperados o parte del estado, como first, second review en este ejemplo de formulario de asistente, y proporciona una forma limpia y agradable de mostrar diferentes partes del componente, y, por supuesto, podrías también enviar eventos, ya sea solo la cadena de eventos o un objeto de evento completo, por lo que es realmente útil y muy práctico, ya sabes, úsalo como lo harías con use reducer.

Pero quiero hablar sobre algunas características recientes y próximas de X state y X state React que me emocionan particularmente. La primera es use interpret. Así que use interpret, el objetivo de esto es interpretar una máquina, crear un servicio, y simplemente devuelve ese servicio. Y ese servicio es un solo objeto, que es una referencia a, ya sabes, la versión interpretada de esa máquina, que nunca cambia. Y por lo tanto, esto lo hace realmente útil en contexto. Así que si fueras a crear un contexto con React, ahora podrías pasar ese servicio a ese proveedor de contexto y usarlo donde quieras, como un asistente. Ahora, lo genial de esto es que, como el servicio no cambia, no va a causar muchos rerenders. De hecho, solo se actualiza una vez, que es cuando se crea el servicio. Así que estás garantizado a no tener ningún renderizado extra. Y así es como usarías esto es por una combinación de dos hooks, use service y use context. Así que tomas el servicio de el contexto, que es ese contexto de servicio, y luego usando el hook use service, podrías usarlo como una máquina. En lugar de pasar una máquina, pasas el servicio, y obtienes los dos mismos valores esperados de la tupla, el estado actual, y la forma de enviar a ese servicio. Y luego puedes usarlo como normalmente. Y así te da la capacidad de tener tanto un estado local como global, e incluso un estado semi-local donde necesitas que algunos estados sean compartidos entre un montón de componentes, pero no con cada componente. Y sin embargo, incluso esto, a veces, aunque previene como un rerenderizado masivo debido a que todo cambia, también puede llevar a demasiados renders si uno de tus componentes

Ahora hablemos de un montón de nuevas características en X State. Y el objetivo de estas características es en gran medida facilitar la especificación y el tipado de contexto, eventos y en el futuro mucho más, como acciones, guardias, etc. Una de estas utilidades es la función creates model. Create model simplemente proporciona una forma agradable de contener tu contexto. Así que al principio puede parecer superfluo, pero veremos algunas ventajas de esto en un minuto. Pasas tu contexto inicial a create model y ahora tienes un user model. Este modelo representa el estado extendido o el contexto de tu máquina. Así que la máquina define los estados finitos, el modelo puede ayudar a definir estados extendidos. También conocido como contexto. Uno de los beneficios de usar este modelo es que hay algunas funciones de utilidad como assign. En lugar de extraer assign de X State como una acción separada, ahora puedes simplemente llamar en este caso a user model.assign y todo es seguro en cuanto a tipos, y hace que sea mucho más fácil asignar valores de esa manera. Pero como mencioné, uno de los mayores beneficios es el uso de TypeScript y hacerlo mucho más fácil para tipar. Entonces, si especificas contexto y eventos en este modelo, ahora este modelo assign será realmente fuertemente tipado. E incluso podrías restringir el tipo de evento que este assign puede tomar. Y esto se infiere correctamente en la máquina, aquí mismo, pasas en tipo te permite especificar la transición para cualquier grupo de eventos que tengan el mismo prefijo. Ahora, los prefijos están delimitados por un punto. Entonces, en este caso, esta transición aquí coincidirá con mouse. Coincidirá con mouse.click. Coincidirá con cosas como mouse.move.out. No coincidirá con eventos como mouse move si es una palabra. No funciona de esa manera. Es por prefijo según la especificación SEX y mouse. Pero esto simplemente facilita mucho agrupar transiciones relacionadas juntas. O eventos relacionados, realmente. En una sola transición. Otro cambio que me emociona es los guardias de nivel superior. Antes, tenías que especificar guardias como si tuvieras alguna condición, si querías que esa condición fuera simplemente la inversa donde es falsa en lugar de verdadera, tenías que especificar una nueva condición. Y ahora, con guardias de nivel superior, podrías simplemente usar estos creadores de guardias como and, or, o not y componerlos juntos de muchas maneras diferentes. Hay dos beneficios para esto. Primero de todo, sé lo que estás pensando.

¿Por qué no simplemente escribir esto en code con, ya sabes, declaraciones if y operadores como esos. Y porque estamos, XA te proporciona la capacidad de serializar guardias, funciona automáticamente con esos guardias serializados dentro de la máquina, por lo que no tienes que hacer referencia al guardia directamente. El guardia puede y debe ser un detalle de implementación y XA te permite dejarlo justo así. Además, esto te permite visualizar completamente estos guardias en una futura versión del visualizador que realmente lo mostrará básicamente como un diagrama de flujo o un árbol de decisiones. Y eso es un beneficio realmente agradable de tenerlo especificado de esta manera.

Así que hay muchos cambios nuevos que vienen en la versión 5 de XState y los describiré brevemente aquí. En primer lugar, todo es un actor. Antes, XState estaba haciendo casos especiales para cosas como callbacks, observables, promesas, otros servicios, y simplemente los convertía internamente en actores para que pudieras generarlos, invocarlos, etc. Pero ahora, la versión 5 de XState simplifica mucho esto y dice, en lugar de hacer casos especiales para esas cosas, estamos tomando la postura de que si es un actor o un objeto similar a un actor, entonces podemos interactuar con él directamente. Así que eso es cualquier cosa que tenga un método de envío y un método de suscripción, simplemente va a funcionar con él. Y también te facilita mucho la creación de tus propios actores para tus propios casos especiales de uso.

Otro cambio que viene es la asignación en orden. Así que anteriormente en la versión cuatro, en retrospectiva, esto fue un poco un error, pero las llamadas de asignación ya no se priorizan inmediatamente, por lo que ahora puedes definir acciones donde una llamada de asignación podría venir más tarde. Y así las acciones se reflejarán correctamente de modo que en lugar de llamar a asignar primero, asignar se llama en orden en su lugar. Y esto es parte de la especificación SCX ML, y también técnicamente es un cambio que rompe la compatibilidad, lo cual es por qué esto va a la próxima versión de X State cinco. Hemos escuchado mucho que TypeScript podría ser un poco doloroso en X State, y eso es porque X State realmente está tratando de empujar los límites de lo que TypeScript puede hacer. Así que la versión cinco va a proporcionar un tipado mucho más fuerte y fácil y una mejor inferencia de tipo también. Además, la versión cinco de X State se está construyendo desde cero para ser modular y como resultado, más pequeña. Así que podrías incorporar solo las cosas que necesitas de X State. Los algoritmos internos han sido completamente renovados y debido a la modularidad, realmente podrías hacer esto tan pequeño como quieras que sea. Y hay muchas más mejoras que vienen en la versión cinco de X State. Te animo a que eches un vistazo a la rama y a las discusiones en GitHub si estás interesado en lo que viene a continuación. Y para cuando se emita esta charla, esperemos que haya una alfa de X State con la que puedas jugar.

Ahora, X State tiene muchos de estos beneficios de tener un formalismo visual en primer lugar, obviamente siendo visualization, pero también siendo capaz de generar automáticamente pruebas, tomar automáticamente análisis y ser capaz de capturar todas las transiciones y cosas que pueden suceder y almacenar eso en algún lugar para que puedas hacer un análisis de eso más tarde y también la generación automática de cosas como testing, y generación de tipos, y generación de documentation, y mucho más que eso. Y por eso es por lo que X State no cae en la categoría normal de herramientas de state management. Es más una orquestación de estados y lo hace de una manera declarativa para habilitar todas estas cosas. Y por eso digo que tenemos un futuro visual para X State porque es mucho más que simplemente ser otra biblioteca de state management. Uno de los ejemplos recientes de esto es el catálogo de X State, que este es en realidad un proyecto realmente, realmente genial, um, y, uh, de Matt Pocock. Y, uh, te permite, um, simplemente tener este catálogo de máquinas y poder interactuar con él directamente y visualizarlo al mismo tiempo. Y este es el inspector de X State, que, um, te recomiendo mucho que lo revises, porque trae nuevas capacidades para visualizar tu estado, uh, y también en ambos sentidos.

Entonces puedes interactuar con el inspector y hacer que el estado cambie y viceversa. Entonces es, um, es como las herramientas de desarrollo de Redux, pero mucho más potentes. Um, entonces, al hablar de, ya sabes, solo este aspecto visual del código, el hecho de que ahora es que hoy en día, gran parte del código que tenemos está realmente atrapado en el mundo del código donde solo tenemos código. Y en mi opinión, esto es difícil de manejar, ¿verdad? Tenemos código con el que tenemos que hablar con el desarrollador o leer los comentarios o algo y simplemente tratar de averiguar qué se supone que representa este código, ya sea que sean características o, um, ya sabes, simplemente cómo se supone que debe funcionar la aplicación.

Y entonces, um, una cosa que podríamos hacer es tener code y diagramas juntos. Pero el problema con esto es que estos diagramas normalmente no están sincronizados con el code. Y entonces, para resolver eso, tenemos soluciones como Code2Diagram donde el diagrama se genera a partir del code. Pero el problema es que es muy unidireccional, ya sea que hagas code a diagrama o diagrama a code. Y diagrama a code es un poco peor porque hace que realmente no puedas tocar el code. Pero todos estos son un paso en la dirección correcta para sincronizar diagramas y códigos juntos. Pero el futuro, en el futuro visual que veo son los diagramas y el code trabajando juntos de modo que, ya sabes, en el futuro podrás editar el code y generar diagramas, o editar los diagramas y generar code y poder editar ese code también. Y entonces vemos esto en muchas áreas diferentes en tecnología y esto es algo que definitivamente quiero llevar al mundo del web development.

Es por eso que estoy comenzando un conjunto de herramientas llamado Stately. Y este conjunto de herramientas va a ser realmente útil para crear visualmente, inspeccionar, testing, analizar, simular estas máquinas de estado y gráficos de estado para tu aplicación. Y en el futuro, no estará restringido solo a los estados x, sino que te permitirá abarcar mucha más lógica, independientemente del lenguaje en el que escribas, y poder compartirlas y colaborar con otros desarrolladores y otros compañeros de equipo en ello. Y entonces, si quieres una vista previa de lo que son estas herramientas y lo que pueden hacer, ve a stately.ai.

Así que con eso, gracias, React Summit. ¿Cómo estás usando máquinas de estado explícitamente en tus aplicaciones? Y si vamos y miramos las respuestas, podemos ver que la mayoría de la gente dijo que sí, un buen 38% dijo que sí, con otras bibliotecas o sin bibliotecas, el 28% dijo que no, todas son implícitas, el 25% dijo que no todavía, pero quieren, y el 11% dijo que sí, con x state. ¿Hay algún resultado sorprendente que veas, David? Hey, sí. Al principio, me sorprendió que tuviéramos sí con otras bibliotecas o sin bibliotecas, porque al menos mucha gente se está dando cuenta de que, ya sabes, las máquinas de estado son importantes y explícitamente modelar la lógica de tu aplicación con máquinas de estado también es importante. Así que me alegra que los desarrolladores estén entendiendo eso cada vez más y espero que mi charla los haya inspirado a quizás usar x states para hacer ese proceso mucho más fácil. Siempre es así, ¿verdad? Vemos una especie de principio de desarrollador o algo que se vuelve más importante y luego se convierte en una herramienta que lo hace realmente fácil para ti. Así que definitivamente voy a estar revisando eso. Así que tenemos un par de preguntas y voy a pasar por ellas. Así que voy a pasar por una de Vasily Shchelkov. ¿Es xtate una biblioteca global de state management, una alternativa a la state management nativa de React, Redux, recoil. Les gusta la idea de tener una visión clara de las transiciones de estado y los eventos pero no tanto del estado global ya que rara vez lo encuentran necesario. Dividido desde uno. Sí, xtate es como quieras hacerlo. Se podría usar de manera global, pero el uso típico es usarlo en el estado del componente local o donde lo necesites. Así que incluso al mencionar eso, y especialmente con los nuevos hooks ahora podrías compartir esos servicios a través de componentes según lo necesites. De esa manera funciona igual que el use reducer nativo de React y también recoil en su modelo de actor. Quiero decir que xtate es más una biblioteca de orquestación de estado que una biblioteca de gestión de estado. Así que hay una diferencia en comparación allí.

Sí, eso tiene sentido, eso tiene sentido. También tenemos otra pregunta de Lulbian. ¿Los parámetros de envío están tipados? ¿CodeCompletion sabe qué parámetros de envío están disponibles? Sí, lo sabe. Entonces, si escribes tus eventos en la máquina, podrías hacer send, empezar a escribir y será capaz de auto-completar los eventos a medida que los escribes e incluso tener los parámetros correctos si los escribes correctamente. En la versión 5, esta tipificación será mucho más fuerte. Así que estén atentos a eso.

Genial, ya estamos esperando eso. Y Arman pregunta, ¿admite middlewares? No lo hace, y la razón es porque el middleware es una especie de concepto diferente. Básicamente, podrías pensar en Xdate como algo mucho más simple que algo que necesita middleware. Xdate es algo a lo que envías eventos, y te suscribes a los cambios de estado. Ahora, cuando esos cambios de estado ocurren, puedes hacer lo que quieras con ellos. Ahí es donde iría tu middleware si quieres, como el registro de eventos, pero también Xdate maneja los efectos secundarios de manera declarativa en forma de acciones. Y eso elimina una amplia clase de middleware que podrías necesitar. Así que sí, todo el modelo de actor, modelo de máquina de estado, no usa middleware porque el middleware es demasiado, ya sabes, abstracto o no abstracto, pero ambiguo y vago. Y no puedes predecir lo que sucede en el middleware, y todo el punto de las máquinas de estado es poder predecir todo. Genial. También tenemos otra pregunta, que es, ¿puedes encadenar comandos de envío o hay un callback o promesa en el envío? El envío es de tipo 'enviar y olvidar'. Entonces envías un evento y luego la máquina lo recibe y hace algo. Es lo mismo que si le dices a alguien que haga algo, como, ya sabes, no vas a esperar a que te digan, de acuerdo, lo entiendo. Tal vez esa sea una mala analogía. Pero sí, el envío es de tipo 'enviar y olvidar'. Genial. Otra pregunta de Eric dice, ¿cómo maneja este util los cambios de comparación de data o necesitas usar data normalizada? La forma en que haces con la data extra es básicamente libre de hacer lo que quieras. Lo pones en contexto y luego puedes cambiarlo. Xstate es lo suficientemente inteligente para saber cuándo realmente cambias el contexto de la data. Así que no necesitas hacer grandes diferencias o algo así. Y también porque xstate tiene el modelo de actor y podrías generar o invocar actores, esos pueden ser pequeños containers de data. Así que si solo quieres suscribirte a los cambios de esos, podrías hacerlo individualmente sin tener que hacer una comparación profunda de todo el objeto. Así que sí.

Genial. Genial. Ahora tenemos una pregunta, realmente me gusta esta próxima pregunta. Imagina que hay alguien en la audiencia que ha escuchado esta charla y piensa que xstate es increíble. Y quieren exponerlo a su equipo. Entonces esta pregunta dice, parece que hay bastantes conceptos nuevos y probablemente sea más difícil de vender para el equipo de desarrollo. ¿Tienes algún tip para una buena forma de probar xstate y conseguir que el equipo de desarrolladores se interese en probar xstate? Claro. Hay un artículo que escribí llamado, no necesitas una biblioteca para las máquinas de estado. Y ese artículo describe cómo comenzar a usar declaraciones switch, seguido por objetos. Y llegar bastante lejos en el camino de usar máquinas de estado en tu aplicación sin demasiada fricción. De hecho, podrías usar el mismo use reducer o lo que quieras, y luego muestra cómo esfuerzo es migrar a xstate cuando lo necesitas. Genial. Tenemos otra pregunta sobre performance. Una de las primeras es compararlo con otras bibliotecas. Dado que la encuesta preguntó si los usuarios estaban usando otras bibliotecas, tienen curiosidad por saber cómo se compara xstate con algunas de las otras bibliotecas de máquinas de estado y qué es lo que realmente lo distingue. Buena pregunta. En realidad no he hecho mucha investigación al respecto. Hay otras bibliotecas de máquinas de estado, pero, sí, no he hecho ninguna investigación de performance allí. Es lo suficientemente rápido, aunque no he escuchado nada malo sobre la performance. Eso tiene sentido. ¿Y cuál es el impacto en la performance de usar React, use state directamente, versus usar xstate? Siempre va a haber un poco de sobrecarga, por eso digo que xstate es más útil para la lógica compleja, porque definitivamente va a superar el intento de hacerlo manualmente. Genial. ¿Recomiendas una o varias máquinas por aplicación? Esta es una pregunta de Radarslav. Depende de las necesidades de tu aplicación. Si tu máquina se vuelve demasiado grande, entonces deberías intentar dividirla en varias máquinas, y esas máquinas actuarán de forma independiente. Así que podrías pensar en cada una de esas máquinas como pequeñas entidades que se comunican entre sí, lo que facilita mucho la organización de tu lógica. Muchas gracias. Pudimos encajar bastantes preguntas en ese corto período de tiempo. Vamos a tener que seguir adelante, así que nos vemos más tarde, David. Espero verte tocar el piano en algún momento. Muy bien. Gracias.