El Futuro Visual de la Gestión de Estado

Rate this content
Bookmark

Aprende cómo el modelado de estado con máquinas de estado y statecharts puede mejorar la forma en que desarrollas la lógica de la aplicación, y obtén un adelanto de herramientas visuales nunca antes vistas que llevarán la gestión de estado al siguiente nivel.

32 min
09 Jun, 2021

Video Summary and Transcription

Esta charla discute el futuro visual de la gestión de estado y el uso de máquinas de estado y statecharts. XState se presenta como una biblioteca de máquinas de estado y statecharts para JavaScript, que proporciona una forma limpia y visualizable de representar máquinas de estado. La charla destaca las características de XState, como su enfoque en el estado y las utilidades para interpretar la máquina como un servicio. También menciona los objetivos futuros de XState, que incluyen visualización, pruebas, análisis y el desarrollo de una suite de modelado de software visual llamada Stately.

Available in English

1. Introducción al Futuro Visual de la Gestión de Estado

Short description:

Hola, mi nombre es David Korshid. Quiero hablarles hoy sobre el futuro visual de la gestión de estado. Las visualizaciones sirven como una especificación exacta de algo que sería difícil de describir solo con texto. La forma en que típicamente codificamos la lógica de la aplicación no se presta bien a un formalismo visual. Aquí es donde entra el reductor, que proporciona una forma de contener toda esta lógica en una ubicación centralizada y conveniente. El envío de eventos es algo realmente bueno.

Soy David K. Piano, prácticamente en todas partes en línea. Y quiero hablarles hoy sobre 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.

2. Introducción a las Máquinas de Estado y los Diagramas de Estado

Short description:

Te obliga a concretar lo que puede suceder en tu aplicación en cualquier momento. Los reductores típicamente contienen declaraciones switch o if para discernir qué debe suceder cuando se recibe un evento. Las máquinas de estado separan de manera clara los comportamientos en estados finitos, evitando estados y transiciones imposibles. Los diagramas de estado llevan el formalismo visual de las máquinas de estado aún más lejos al introducir jerarquía y permitir una representación más clara de la lógica compleja. XState fue creado para proporcionar un formalismo visual matemáticamente riguroso para los diagramas de estado.

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.

3. Introducción a XState y sus características

Short description:

XState es una biblioteca de máquinas de estado y diagramas de estado para JavaScript que permite a los desarrolladores representar máquinas de estado y diagramas de estado de manera limpia y visualizable. Proporciona un enfoque centrado en el estado, separando los comportamientos en estados finitos y especificando transiciones basadas en eventos. XState se puede utilizar con React y otros frameworks populares, proporcionando utilidades para interpretar la máquina como un servicio y manejar los cambios de estado. XState React ofrece nuevos hooks como useInterpret y uSelector para mejorar la gestión del estado. Además, XState introduce nuevas características como create model.

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.

4. XState: Modelo, Etiquetas, Comodines y Más

Short description:

Esto te permite definir un modelo tanto para el contexto como para los eventos, lo que facilita su uso en tus máquinas. Las etiquetas proporcionan una forma sencilla de reutilizar las máquinas de estado en diferentes contextos. XState v5 introduce comodines parciales para especificar eventos y guardias de nivel superior para transiciones condicionales. Simplifica el modelo de actores, corrige errores, mejora la tipificación de TypeScript y hace que la biblioteca sea más modular y más pequeña. XState no es solo una biblioteca de gestión de estado.

tanto para el contexto como para los eventos y en el futuro acciones y cosas así, lo que facilita mucho su uso en tus máquinas o en múltiples máquinas. Esto proporciona una forma más sencilla y una forma más segura en cuanto a tipos de trabajar con un modelo de datos específico con tus máquinas de estado.

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.

5. XState: Metas Futuras y Stately

Short description:

XState tiene muchas metas más allá de la gestión de estado, incluyendo visualización, pruebas, análisis y generación automática. XState Inspect permite la visualización en tiempo real de las máquinas de estado. El recientemente anunciado xstatecatalog.com proporciona ejemplos útiles de máquinas de estado. XState tiene como objetivo abordar los desafíos de comprensión del código a través de documentación, diagramas y diagramas ejecutables. La futura suite de modelado de software visual, Stately, permitirá la colaboración y comprensión de la lógica de la aplicación en todos los niveles del stack. Visita stately.ai para suscribirte a la lista de correo.

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.

QnA

Q&A: Adopción de Máquinas de Estado y Pruebas en XState

Short description:

Tenemos el mismo número de votos para dos respuestas: la mitad de las personas respondieron que aún no, sí, no estoy usando una máquina de estado, y la otra mitad respondió que sí, la uso con una biblioteca. Las máquinas de estado tradicionalmente han sido un tema académico, pero ahora cada vez más personas las están utilizando para modelar el estado de sus aplicaciones. Las pruebas en XState son excelentes, con funciones puras para probar máquinas de estado y la biblioteca Xstate-test para probar aplicaciones completas.

desde nuestro canal de Discord, pero antes de las preguntas para ti, echemos un vistazo a lo que la gente respondió a tu pregunta. Así que abro Slido, y wow, eso es realmente interesante. Tenemos el mismo número de votos para dos respuestas y están dejando estas dos con una gran diferencia. Así que la mitad de las personas respondieron que aún no, sí, no estoy usando una máquina de estado, y la otra mitad de las personas respondió que sí, la uso con una biblioteca. Eso es realmente interesante.

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.

Testing, Learning Curve, and Adoption

Short description:

Xstate permite simular fácilmente efectos secundarios y probar efectos. La curva de aprendizaje de Redux a Xstate es baja, con soporte para máquinas combinatorias. Migrar de Redux a Xstate es más fácil con menos código y gestión incorporada de efectos secundarios. Xstate es una opción natural para los usuarios de Redux, Vuex y Ngrx. Ayudar a los desarrolladores a adoptar nuevas tecnologías es crucial para su éxito.

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.

Using Xstate with NGRX for Visualization

Short description:

En teoría, es posible utilizar Xstate en combinación con NGRX para la visualización. La función machine.transition se puede utilizar con cualquier biblioteca existente de gestión de estado. El objetivo es facilitar al máximo la migración a Xstate.

¿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.

Using X State between Frameworks

Short description:

X state te permite utilizar la misma máquina en cualquier framework o incluso sin ningún framework. Es un punto natural de unidad para los desarrolladores que utilizan diferentes frameworks como Angular, React, Svelte o Vue.

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.

Q&A: T-shirt and Future of X State

Short description:

Antes de pasar a la siguiente pregunta, permítanme abordar la pregunta del fanático sobre mi camiseta. La camiseta es de los key framers, un stream en vivo semanal donde damos vida a interfaces de usuario imaginativas. Puedes conseguirla en keyframe.rs. Ahora, hablemos sobre el futuro de X state. Estamos trabajando arduamente en la versión cinco, actualizando el visualizador y planeando crear un editor de arrastrar y soltar y un registro para la creación colaborativa de máquinas. Visita stately.ai para mantenerte actualizado. ¡Gracias por tenerme aquí!

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.

Check out more articles and videos

We constantly think of articles and videos that might spark Git people interest / skill us up or help building a stellar career

Vue.js London Live 2021Vue.js London Live 2021
34 min
Everything Beyond State Management in Stores with Pinia
Top Content
When we think about Vuex, Pinia, or stores in general we often think about state management and the Flux patterns but not only do stores not always follow the Flux pattern, there is so much more about stores that make them worth using! Plugins, Devtools, server-side rendering, TypeScript integrations... Let's dive into everything beyond state management with Pinia with practical examples about plugins and Devtools to get the most out of your stores.
React Advanced Conference 2022React Advanced Conference 2022
30 min
Using useEffect Effectively
Top Content
Can useEffect affect your codebase negatively? From fetching data to fighting with imperative APIs, side effects are one of the biggest sources of frustration in web app development. And let’s be honest, putting everything in useEffect hooks doesn’t help much. In this talk, we'll demystify the useEffect hook and get a better understanding of when (and when not) to use it, as well as discover how declarative effects can make effect management more maintainable in even the most complex React apps.
JSNation 2023JSNation 2023
29 min
Modern Web Debugging
Few developers enjoy debugging, and debugging can be complex for modern web apps because of the multiple frameworks, languages, and libraries used. But, developer tools have come a long way in making the process easier. In this talk, Jecelyn will dig into the modern state of debugging, improvements in DevTools, and how you can use them to reliably debug your apps.
React Summit Remote Edition 2020React Summit Remote Edition 2020
30 min
React Query: It’s Time to Break up with your "Global State”!
Top Content
An increasing amount of data in our React applications is coming from remote and asynchronous sources and, even worse, continues to masquerade as "global state". In this talk, you'll get the lowdown on why most of your "global state" isn't really state at all and how React Query can help you fetch, cache and manage your asynchronous data with a fraction of the effort and code that you're used to.
JSNation 2022JSNation 2022
21 min
The Future of Performance Tooling
Top Content
Our understanding of performance & user-experience has heavily evolved over the years. Web Developer Tooling needs to similarly evolve to make sure it is user-centric, actionable and contextual where modern experiences are concerned. In this talk, Addy will walk you through Chrome and others have been thinking about this problem and what updates they've been making to performance tools to lower the friction for building great experiences on the web.
React Day Berlin 2022React Day Berlin 2022
22 min
Jotai Atoms Are Just Functions
Top Content
Jotai is a state management library. We have been developing it primarily for React, but it's conceptually not tied to React. It this talk, we will see how Jotai atoms work and learn about the mental model we should have. Atoms are framework-agnostic abstraction to represent states, and they are basically just functions. Understanding the atom abstraction will help designing and implementing states in your applications with Jotai

Workshops on related topic

React Advanced Conference 2021React Advanced Conference 2021
174 min
React, TypeScript, and TDD
Top Content
Featured WorkshopFree
ReactJS is wildly popular and thus wildly supported. TypeScript is increasingly popular, and thus increasingly supported.

The two together? Not as much. Given that they both change quickly, it's hard to find accurate learning materials.

React+TypeScript, with JetBrains IDEs? That three-part combination is the topic of this series. We'll show a little about a lot. Meaning, the key steps to getting productive, in the IDE, for React projects using TypeScript. Along the way we'll show test-driven development and emphasize tips-and-tricks in the IDE.
React Summit 2020React Summit 2020
96 min
Rethinking Server State with React Query
Top Content
Featured Workshop
The distinction between server state and client state in our applications might be a new concept for some, but it is very important to understand when delivering a top-notch user experience. Server state comes with unique problems that often sneak into our applications surprise like:
- Sharing Data across apps- Caching & Persistence- Deduping Requests- Background Updates- Managing “Stale” Data- Pagination & Incremental fetching- Memory & Garbage Collection- Optimistic Updates
Traditional “Global State” managers pretend these challenges don’t exist and this ultimately results in developers building their own on-the-fly attempts to mitigate them.
In this workshop, we will build an application that exposes these issues, allows us to understand them better, and finally turn them from challenges into features using a library designed for managing server-state called React Query.
By the end of the workshop, you will have a better understanding of server state, client state, syncing asynchronous data (mouthful, I know), and React Query.
React Summit Remote Edition 2021React Summit Remote Edition 2021
71 min
State Management in React with Context and Hooks
WorkshopFree
A lot has changed in the world of state management in React the last few years. Where Redux used to be the main library for this, the introduction of the React Context and Hook APIs has shaken things up. No longer do you need external libraries to handle both component and global state in your applications. In this workshop you'll learn the different approaches to state management in the post-Redux era of React, all based on Hooks! And as a bonus, we'll explore two upcoming state management libraries in the React ecosystem.