Café con Tech

State Machines with David K. Piano!

August 30, 2021 Matias Hernández / David K. Piano Season 3 Episode 7
Café con Tech
State Machines with David K. Piano!
Chapters
Café con Tech
State Machines with David K. Piano!
Aug 30, 2021 Season 3 Episode 7
Matias Hernández / David K. Piano

This week's episode was focused on learning what state machines are, and who better to drive us through this path than the creator of XState David Kourshid, or maybe better known as David K. Piano.

David answer questions about concepts and ideas around why state management can be a difficult business and how XState can help to simplify the situation.

Found David on Twitter and definitely check his new adventure with stately.ai and signup for the newsletter there.

David also does streams that you can check in Keyframes site. And if you want to learn more about state machines and xstate check discord.gg/xstate

Music Credits
Opening and Outro Music
by DanoSongs https://danosongs.com/
Background Music Music:
Cool Rock by Kevin MacLeod Link: https://incompetech.filmmusic.io/song/3925-iron-bacon License: https://filmmusic.io/standard-license


Support the show (https://www.buymeacoffee.com/matiasfha)

Show Notes Transcript

This week's episode was focused on learning what state machines are, and who better to drive us through this path than the creator of XState David Kourshid, or maybe better known as David K. Piano.

David answer questions about concepts and ideas around why state management can be a difficult business and how XState can help to simplify the situation.

Found David on Twitter and definitely check his new adventure with stately.ai and signup for the newsletter there.

David also does streams that you can check in Keyframes site. And if you want to learn more about state machines and xstate check discord.gg/xstate

Music Credits
Opening and Outro Music
by DanoSongs https://danosongs.com/
Background Music Music:
Cool Rock by Kevin MacLeod Link: https://incompetech.filmmusic.io/song/3925-iron-bacon License: https://filmmusic.io/standard-license


Support the show (https://www.buymeacoffee.com/matiasfha)

Español

[00:00:00] Matias: Bienvenidos de nuevo a otro episodio de cafe con tech en esta temporada especial hoy me acompaña David Khurshid o quizás más conocido como David K piano. El defensor de las máquinas de estado. Hola David, gracias por venir al programa. 

[00:00:16] David: Hola, muchas gracias. 

[00:00:17] Matias: Lo haremos, hablaremos de las máquinas de estado y todo ese concepto en las webs y el desarrollo web.

Pero antes de nada, ¿puedes presentarte un poco al público que, quizás no te conozca?

[00:00:31] David: Claro. Sí. Mi nombre es David . He sido un desarrollador web. Pensando en unos 10 años, he sido, usted.

ya sabes, trabajando en todas partes, desde startups hasta recientemente en Microsoft. Y, de hecho, hace poco dejé mi trabajo en Microsoft para independizarme por completo y empezar mi propio negocio. Pero sí, también he estado hablando por todo el mundo, algo que echo mucho de menos y espero volver a hacerlo, y los temas de los que me encanta hablar son las interfaces de usuario frontales, las animaciones.

Máquinas de estado en gráficos de estado. También soy el creador de la biblioteca xstate, que es una biblioteca para crear máquinas de estado y gráficos de estado en JavaScript o TypeScript. 

[00:01:14] Matías: Eso es impresionante. Puedo preguntarte ¿Ya has descrito en otro lugar? ¿Cuál es tu próximo paso? ¿Puedes darnos tal vez un vistazo?

[00:01:23] David: Sí, en realidad no lo dije explícitamente. Sólo mencioné, dejé Microsoft y di algunas pistas, pero en resumen voy a tratar de hacer que xstate sea algo a tiempo completo. Básicamente, voy a crear una empresa que ofrezca algunas herramientas y servicios realmente útiles para que cualquier desarrollador web pueda crear máquinas de estado y gráficos de estado, y también pueda hacerlo visualmente.

Analizarlos y compartirlos y colaborar. Y no sé, tenemos un montón de cosas planeadas. 

[00:01:59] Matias: Wow, eso suena increíble. Así que comenzando en el tema principal aquí que es alrededor de todo su contenido y el trabajo en las máquinas de estado, esto es algo que aprendí o tipo de aprendido y durante mi licenciatura y nunca. He oído hablar de eso nunca más. Hasta hace poco relacionado con las implementaciones de UI en el desarrollo web

¿Por qué? Por qué las máquinas de estado caen en el, en las grietas del desarrollo y luego de repente la investigación como una solución para un gran problema.

[00:02:36] David: En realidad es una pregunta muy interesante porque. Como usted mencionó, las máquinas de estado se enseñan generalmente en un entorno académico donde es para supongo que se llaman deterministas, autómatas finitos, donde usted los está utilizando para implementar reg Xs o hacer como, sólo tipo de creación de aceptores y cosas por el estilo.

Y el puente entre eso y su uso en interfaces de usuario y aplicaciones no es un puente obvio, pero los gráficos de estado fueron creados en 1989. Y eso reveló cómo las máquinas de estado pueden ser usadas para cosas más allá de lo que su entorno académico implica que son usadas.

Y sí, así que cuando, cuando pensamos en como los flujos de trabajo y cosas por el estilo, esos son también los casos de uso obvio donde se podría ver, oh, yo podría utilizar una máquina de estado aquí o un gráfico de estado. Y

[00:03:28] Matias: Sí, es tan difícil para un nuevo comercio en el desarrollo de JavaScript en la interfaz de usuario para averiguar lo que la máquina de estado son y por qué diablos se debe utilizar que si usted tiene muchas otras herramientas para manejar su estado. Así que creo que la primera pregunta que cualquier persona debe hacer es qué, ¿por qué es el estado es un problema que necesita ser manejado?

Y qué es un estado.

[00:03:56] David: Claro. Así que cuando hablamos de ver máquinas, realmente tiene sentido hablar de comportamientos. En primer lugar, cuando estás creando una aplicación, podría estar en uno de muchos comportamientos. Así que, por ejemplo, si estás intentando cargar datos, entonces la carga de esos datos es un comportamiento y puede que quieras permitir que ocurran ciertas cosas o prohibir que ocurran ciertas cosas en ese comportamiento.

Y así, cuando los datos se cargan finalmente, es un comportamiento diferente. Así que por comportamientos, me refiero a cómo su aplicación va a reaccionar a ciertos eventos. De hecho, usted podría pensar en como, usted. Tenemos comportamientos, por ejemplo, podría estar durmiendo o podría estar despierto y reaccionar a diferentes eventos dependiendo de si estoy durmiendo o despierto.

Y además no puedo hablar dormido y despierto al mismo tiempo. Así que esa es una de las claves. Sí. Esa es una de las claves de lo que es la máquina de estado, es que sólo puedes estar en uno de un conjunto finito de estados a la vez. Así que... 

[00:04:58] Matías: Y tratando de volver a otra pregunta. Por qué en el desarrollo de la interfaz de usuario el estado se convirtió en un problema que necesitaba soluciones complejas como una máquina de estado para manejar este estado. ¿Por qué el desarrollo de la interfaz de usuario requiere ese tipo de herramientas sólo para manejar estas zapatillas?

[00:05:19] David: Bueno, es sobre todo porque una palabra que describe los comportamientos antes mencionados en nuestras aplicaciones, no son realmente explícitos. así que nosotros, cuando estamos haciendo nuestras aplicaciones, normalmente tenemos un estado de carga y una fecha de éxito. Podríamos tener sólo una variable booleana que dice está cargando y podríamos pensar que eso está bien.

Como, todo lo que tenemos que hacer es comprobar el estado de que se está cargando booleano para ver, bien, ¿qué debemos hacer a continuación? Pero el problema viene cuando se agrega más y más de esas variables booleanas, como ahora es el error, y entonces usted tiene que comprobar como, ¿la promesa realmente éxito? Así que usted no tiene es con éxito en.

Y por lo que ahora tiene que asegurarse de que es la carga. No es cierto al mismo tiempo que su éxito es cierto y multiplicado este problema veces como un centenar. A medida que tu aplicación se vuelve más compleja y empiezas a añadir más características y tienes que gestionar diferentes cosas que suceden al mismo tiempo. Porque las aplicaciones, no son sólo esta gran bola de funcionalidad donde un usuario podría hacer cualquier cosa en cualquier momento las aplicaciones tienen modos.

Y así esos modos son algo que claramente queremos separar en ya sabes, diferentes comportamientos. Así que. Está claro lo que puede suceder en la aplicación en cualquiera de esos modos dados. Usted sabe, por ejemplo, como si usted tiene una máquina y usted sabe, usted quiere decir, si pulso este botón, algo debe suceder.

Si la máquina está apagada y obviamente ese botón no debería hacer nada. Así que en lugar de tener un booleano que dice está apagado o está encendido hacer esto, entonces usted acaba de definir diferentes modos en el modo de apagado, en. Y luego se define el comportamiento para cada uno de esos modos. Y así, eso es lo que las máquinas de estado realmente ayudó con la organización de los estados y los diferentes modos.

[00:07:00] Matias: entonces, ¿cómo un modelo mental diferente y en el proceso de desarrollo de la interfaz de usuario? Creo que cuando react llegó la mayoría de la gente empieza a juguetear con el estado porque es algo natural en el framework y montamos flux, montamos Redux. En todo dentro de eso, eh, el estado de gestión de la interfaz de usuario, la gestión del estado del servidor, y la gestión de varios estados, todo dentro de eso.

Pero lo que has descrito es un poco diferente. No es sólo, es como, creo que hay carga isError muestra es realmente bueno porque todo el mundo puede entender. Pero al mismo tiempo, es realmente diferente del modo que usted está describiendo. Como es. La colección de la recogida de datos o cómo usted describe el estado es diferente en el mundo de los reactores.

¿Cómo se definen estos estados? Permítanme reformularlo. ¿Cómo llegó a la conclusión de crear un estado X para intentar implementarlo en los marcos actuales?

[00:08:05] David: así que empecé a crear xstate. En realidad fue uno de mis primeros trabajos. Nosotros, teníamos como una gran aplicación donde teníamos diferentes métricas. Los flujos de trabajo y que eran muy, muy complejo. Como si fuera uno de esos grandes formularios de asistente donde si se hace clic en una cosa, entonces usted podría obtener diferentes campos que aparecen y luego tienes que hacer clic en el siguiente paso.

Y luego, si eliges algo diferente y vuelves, tienes que manejar una cierta lógica para ello. Se volvió realmente complejo muy rápidamente. Así que como un desarrollador junior, yo estaba tratando de encontrar lo que son algunos mejores patrones que podría no saber de. Eso realmente me ayudó a simplificar esta lógica en el declarativo.

Sí. Porque yo soy un estudiante visual, así que realmente quiero ver algo donde podría tanto visualmente diagrama y la aplicación de código. Y así es cuando empecé a aprender sobre las máquinas de estado y los gráficos de estado. Y cuando busqué en ellos, me di cuenta de que, ya sabes, hay algunas bibliotecas sobre esto, pero ninguna que sea realmente como usuario o desarrollador amigable, Los marcos que estamos utilizando todos los días, como angular y reaccionar y por una buena razón, porque esos marcos tipo de proporcionar sus propias ideas de gestión de estado bendito.

Así, por ejemplo, Angular proporciona RX reacciona, proporciona sus ganchos. En el momento en que era como establecer el estado en sub UX proporciona que otras cosas o sí, Vue proporciona VueX. Y así que quiero crear X fecha para crear un verdadero marco agnóstico una manera de crear estas máquinas de estado y gráficos de estado donde no estamos considerando sólo el evento, pero estamos considerando tanto el estado finito y los eventos. 

[00:09:36] Matias: Lo que siento es esta diferencia de cómo solíamos desarrollar una aplicación react en particular que estoy escribiendo react es que necesitas pensar en todos los estados posibles. Para definir la máquina de estados. Y eso, obviamente, te da una especie de espacio de, para jugar. Pero el habitual, la perspectiva habitual es que tipo de ejecutar con lo que tienes y luego añadir más cosas.

A continuación, añadir más, useState ganchos y el silencio, y luego, de repente, refactorizar y empezar a utilizar un useReducer. Y tipo de tratar de imitar la idea de un estado que la transición en el medio, pero sigue siendo corto. Así que en el mundo de react en particular, ¿qué tan lejos está react de las utilidades de react de 

implementación de máquinas de estado. Y porque sé que desarrollar otra herramienta y tipo de en el medio, el reductor useEffect, que soy tipo de fan de él porque realmente útil. Pero qué tan lejos estamos con las herramientas actuales en react u otros frameworks, B dos implementación de máquinas de estado y cómo podemos mover a eso porque los desarrolladores que no sabe acerca de la máquina en absoluto, es tipo no enseñó en cualquier lugar.

[00:10:59] David: Sí, y obviamente estamos tratando de resolver eso mediante la creación de un montón de materiales educativos y tutoriales para que los desarrolladores aprendan más sobre las máquinas de estado desde los gráficos de estado. Pero en cuanto a lo lejos que estamos de que yo, yo diría que estamos bastante cerca y lejos al mismo tiempo con ganchos reaccionar para introducir el concepto o no el concepto, pero sólo hay la noción en reacciona componentes de ambos estados basados en eventos.

Que es para lo que se usan los reductores y los efectos declarativos. El problema es que ambos están separados. Así que los efectos se ejecutan en el efecto de uso, gancho en respuesta a alguna pieza arbitraria de los datos que cambian. Y eso no es ideal. Eso no es realmente la forma en que pensamos como desarrolladores, pensamos como, bien, cuando este evento sucede, Hacer estos actos o hacer estos efectos y luego cambiar los estados.

No pensamos como cambiar esta fecha y en base a lo que cambió, ya sabes, ejecutar este efecto, eso es algo implícito. Y por eso mencionaste el uso del reductor de efectos. Eso es un paso para acercarse al modelo xtate de efectos declarativos y estados basados en eventos. Así que tienes razón.

Al igual que el, la forma de acercarse a ella es utilizar realmente reductor porque eso va a. Reforzado el modelo mental de enviar eventos para cambiar los estados. Y a partir de ahí es en realidad un salto bastante corto para ir a la plena en xstate. Y así el gancho useMachine en xstate react, en realidad se parece mucho a usar reducer.

Así que ese factor de arrecife en realidad no es tan malo.

[00:12:32] Matias: Sí, ese es uno de los temores de muchos desarrolladores en torno a que está bien. Quiero empezar a usar esta nueva herramienta brillante que es un completo tiene sentido para mí, pero también tengo que enseñar que a ellos. Equipo y realmente refactorizar las cosas para que funcione, lo difícil que podría ser eso. Como voy a tomar mi proyecto actual y luego voy a empezar a añadir X estado o más de, Una pregunta es lo difícil podría ser refactorizado que en otra pregunta es lo que es una especie de el mejor caso de uso para vender muchos de X estado en el.

[00:13:11] David: La dificultad para la refactorización, en realidad no es demasiado difícil. Y la razón es porque X state funciona a nivel local. En primer lugar, si quieres un estado global, al igual que Redux, podrías fácilmente poner X state que se llaman servicios, que son instancias de máquinas. Usted podría poner eso en el contexto de uso y luego simplemente usarlo en todas partes.

Y también vas a evitar muchos de esos problemas de renderización que encontrarás con sólo poner cualquier estado en contextos de uso. Así que X reaccionan es más inteligente sobre eso, pero de todos modos, la refactorización es sólo un ya sabes, lo haces poco a poco, por lo que podrías hacerlo un componente a la vez, una pequeña parte de la aplicación a la vez hasta que finalmente todo está representado por el estado X.

Y los beneficios que obtienes de ello, ¿son el número uno? A veces, de hecho, muy a menudo conduce a un código más corto porque xstate tiene esta representación de objetos donde una gran cantidad de la placa de caldera de código que habría tenido que escribir para la gestión de los efectos declarativos y la transición de los estados y sólo la organización de la lógica.

Todo eso ya está incorporado en el.

El modelo xstate y los otros mayores puntos de venta. Y esto de hecho fue un punto de venta para mí, para los gráficos de estado fue El visualizador. Así que la capacidad de visualizar e inspeccionar sus máquinas de estado en tiempo real como usted está trabajando en su aplicación. Y eso es, eso es un enorme valor beneficios para los equipos de desarrollo, porque ahora no tienen que ver a través de código y tratar de leer todo y entender cómo funciona.

En cambio, podrían tener una visión muy clara de lo que se supone que es la lógica de la aplicación y aprender a leer un diagrama de estado no es una gran curva de aprendizaje porque sólo estás siguiendo flechas. Estás en una caja. Sigues la flecha y ahora estás en una caja diferente. Así que 

[00:14:59] Matías: Sí. Ya que mencionaste que seguir los diagramas de estado o el diagrama de la máquina de estado es el tipo de habilidad que un desarrollador necesita para empezar a jugar con xstate. ¿Cuál es el conocimiento básico que se necesita para empezar a trabajar?

[00:15:18] David: Bueno, creo que en, al principio, como habría dicho que era usted, usted tiene que tener una buena comprensión de la máquina de estado desde el estado. Pero honestamente en este momento sólo tiene que tener una buena comprensión de uso reductor. Así que la idea de cambiar el estado basado en el Pence, porque usted podría utilizar X fecha como un reductor de uso mucho más corto y, ya sabes, podrías usarlo como quieras.

En lugar de tener que definir todos los estados finitos de los frentes, podrías usar la máquina con un solo estado y luego editar lo que se llama contexto o extendido. Usted, usted puede editar eso como quiera. Y más tarde volver y leer el factor. Así que ese es el punto de partida inicial.

Y usted sabe, es, no es mucho de una curva de aprendizaje para llegar allí. Y una vez que aprendas más conceptos sobre máquinas de estado y gráficos de estado, entonces podrás refactorizar tus máquinas de estado para que sean más robustas. 

[00:16:10] Matías: ¿Mencionas un concepto aquí? Máquina que por lo que entiendo, es que una representación de la máquina de estado real que está realizando las acciones y la gestión de eventos, pero ¿cómo se puede tipo de describir el concepto de máquina y lo que hace la máquina.

[00:16:28] David: Así que una máquina puedes pensar en ella como un reductor con reglas. Así que si piensas en tus reductores normales que creas, ya sea que hayas usado el gancho reductor usado o usado Redux un reductor es típicamente como si tuvieras un gran interruptor. Y basado en lo que los eventos o lo llaman acción. Pero lo que los eventos entra, se cambia el estado basado en que con las máquinas, se agrega una capa extra a eso.

Así que en lugar de basarse en el evento, se basa en los estados. Así que es como, bien, ¿estoy en los estados de carga? Muy bien. ¿Qué son como ahora qué eventos entraron? Así que va la fecha a continuación, los eventos, y luego se determina lo que el próximo estado es y lo que la acción. Para ese estado son, por lo que es la principal diferencia allí.

Así que usted, usted podría pensar en una máquina, básicamente el mismo que el reductor, pero redujeron. ¿Así que también maneja acciones declarativas o efectos declarativos realmente? 

[00:17:25] Matías: Sí. Y, sólo para mantener la mentalidad de principiante aquí mencionaste los efectos declarativos. ¿Qué son y en qué se diferencian de los efectos simples? ¿Por qué los nombras como declarativos frente a los imperativos? Que me imagino que todavía hay eso.

[00:17:46] David: Sí. Sí. Así que los efectos declarativos son sólo una forma de decir que estos son los efectos que deben ocurrir. Así que uno.

diferencia como los efectos imperativos significaría que a medida que usted está pasando por la función Y tratando de determinar el siguiente estado, también está ejecutando esos efectos. No hay absolutamente ninguna forma de rastrearlos porque, ya sabes, los efectos son de fuego y se olvidan una vez que los has ejecutado, se ejecutan.

Y la función, el valor de retorno de la función sólo va a ser ese estado. así que no tienes, y así es como por ejemplo, thunk, middleware y Redux funciona también. Que los reductores sólo devuelven estados. No hay ninguna indicación de qué efectos deben ser ejecutados. Los efectos declarativos son básicamente una forma de decir

aquí es un array de todos los efectos que deben ser ejecutados por algo. Así que sin ejecutarlos, es solo una descripción de por favor ejecuta este efecto cuando tengas la oportunidad. Así que eso es el efecto declarativo.

[00:18:44] Matias: Y usted, y por lo que la máquina de estado tienen estos conservación. El concepto de evento y el concepto de efecto declarativo y todos los trabajos juntos que el efecto del enfoque, desencadenar o el almuerzo cuando tienen cierto evento sucede. Así que sustituyó a la totalidad, la placa de la caldera y la complejidad de uso efecto gancho.

Eso es lo que el cambio de valor cuando todo el mundo ha cambiado y todo eso, que significa que la declaración del código para crear la máquina de estado puede ser. Larga, verdad. Difícil como la escritura. Sí. El nombre del evento, el nombre de la transición, y luego el, el efecto que tiene que suceder cuando incide sucede. ¿Es eso complejo o suena raro cuando lo digo.

[00:19:31] David: Eso es realmente un pensamiento común que oh, estamos, estamos introduciendo un montón de complejidad al hacer esta gran definición de la máquina de estado. Pero en realidad, no se está introduciendo complejidad. Es sólo hacer la complejidad que ya existe. Muy claro. No estamos añadiendo ninguna complejidad adicional.

Es sólo una manera de organizar como los diferentes estados y transiciones que podrían ocurrir en estos estructura de objeto único. Y como he mencionado antes, xstate utiliza una estructura en la óptica, pero sólo podría abstraer las cosas en las variables y funciones y hacer que se vea un poco más limpio. También podrías, si tienes una máquina realmente grande podrías usar lo que se llama indicaciones.

Y así podrías invocar una máquina diferente que contenga un comportamiento encapsulado. Así que usted no tiene que tener una máquina enorme que trata de hacer todo

[00:20:22] Matias: puedes tener una máquina de máquinas 

[00:20:25] David: Sí. Sí. 

[00:20:26] Matias: composición completa hasta el final. La otra cosa que me encuentro cuando estaba trabajando con use reducer es el, a veces el efecto depende un poco, un poco. Así que puedes actuar, no puedes realmente moverlo fuera de la función para que se vea más limpio porque sí, esa es la única razón por la que quieres que lo mueva.

¿Qué pasó aquí con el estado X? Puede usted, lo que tiene el efecto que desea depende de algunos datos que es, que pertenece al interior del componente

[00:21:00] David: así que todo en xstate y, ya sabes, las máquinas de estado y los gráficos de estado en general, todo funciona mediante el envío de eventos. Esa es la abstracción primaria que está enviando o recibiendo eventos. Y así es básicamente como todo funciona en la, ya sabes, máquina de estado, gráfico de estado, modelo de actor. Así que cuando algunos datos cambian de reacciona, ya sea un cambio de prop o algo más, la máquina tiene que saber sobre él mediante la recepción de un evento.

Y así lo harías es sólo una pequeña llamada de efectos de uso donde podrías enviar eventos a la máquina cuando ese pedazo de datos. Sí. 

[00:21:37] Matías: Tiene sentido y completamente sentido. ¿Qué pasa con la depuración y las pruebas? Las otras piezas de todo proceso de desarrollo mueren, todo falla en algún momento. Entonces, ¿cómo se depuran estas diferentes lógicas?

[00:21:49] David: Una de las bellezas de las máquinas de estado es que, como todo son eventos, como acabo de decir, una depuración o una prueba se convierte en la reproducción de esos eventos. Así que es como probarías cualquier otro reductor. Reproducimos un conjunto de eventos y nos aseguramos de que estamos en los estados que deberíamos estar.

Y porque también tienes la noción de acciones declarativas, también podrías afirmar en cualquier paso de ese proceso, que las acciones correctas están siendo activadas, ya sabes, en ciertos estados y en cuanto a la depuración también, podrías insertar declaraciones de registro como acciones. Y, ya sabes, podrías depurar como cualquier otro programa, pero también siendo una máquina de estados, podrías también separarte completamente de la aplicación y podrías visualizar lo que está pasando y ser capaz de comprobar errores en la lógica y ver, oh, esta transición, no está donde debería estar.

En realidad, debería estar aquí y poder comprobarlo antes de ejecutarlo en la aplicación. 

[00:22:47] Matias: Sí, eso es, eso es increíble para tomar realmente toda la lógica fuera del componente de la cosa UI. Y entonces puedes hacer lo que quieras con eso. Una cosa que me olvidé de preguntar es otro concepto que ha muestra mucho es la transición, ¿verdad? No se utiliza en, entre el otro proceso o marcos, pero, por lo que es.

[00:23:13] David: Una transición. Sí. Un cambio entre estados basado en un evento. Así que, por ejemplo, si estoy durmiendo, eso es un estado y serían eventos como que suene el despertador. Ahora estoy en el estado despierto. Así que la transición de dormido a despierto Y yo podría hacer algunas acciones o también la transición podría tener un, lo que se llama una guardia, que por ejemplo, si estoy en el sueño muy profundo, como estoy muy cansado.

Entonces puede que no pase al estado de vigilia cuando suene la alarma. Quiero decir, con suerte lo haré. Pero sí, por lo que es sólo un cambio de estado basado en un evento. Y siempre es debido a un evento, así es como todo sucede con, ya sabes, máquinas de estado y gráficos de estado.

[00:23:56] Matias: Y puedes disparar efectos o, u otros eventos en el proceso de transición.

[00:24:02] David: Sí. Sí, se puede. De hecho, esa es una, esa es en realidad una técnica muy útil, quiero llamarla técnica avanzada de máquinas de estado y gráficos de estado, donde si recibes un en eventos, también podrías como enviarte a ti mismo en el evento o podrías enviar otra máquina en eventos y, ya sabes, hacer cosas.

[00:24:19] Matias: Y es que eso puede ayudarte a orquestar flujos de trabajo difíciles o complejos. 

[00:24:26] David: Sí. 

[00:24:27] Matías: Que. Qué más me falta sobre el material de contenido del estado X. Sé que tienes algún material en egghead. Sé que hay el sitio con un montón de documentación. Sé que hay una especie de lista curada de X estado de las máquinas ya se envían en listo para usar.

Qué más puede encontrar la gente por cierto, todo eso en las notas del programa.

[00:24:52] David: Sí. Así que en X date la documentación, hay recursos donde hay cientos de recursos escritos por otras personas sobre ya sabes, cómo hacer máquinas y cómo usar xstate en tus aplicaciones. También hay un recurso realmente bueno llamado xstate, catálogo de escritorio. Dot com. Y eso contiene una colección de máquinas muy útiles que puedes visualizar al mismo tiempo.

Mientras lees la documentación, también estamos creando un montón de tutoriales y ejemplos que van a estar en el repositorio. Así que confía en mí, una gran cantidad de material educativo está por venir. 

[00:25:27] Matías: Vale, sí, lo sé seguro. Y eso siempre es una ayuda pero en el mundo de la gestión de estados, es decir, no estoy seguro si lo que pasa en otros frameworks, pero por lo menos en react es una especie de gran, gran problema y concepto que todos discutieron. X estado es fácilmente en una pequeña esquina de toda la cosa. Como la gente siempre está hablando de redux todavía contextos y otras herramientas como SWR o react-query.

Entonces, ¿cómo puede el estado S X asumir de alguna manera el problema de la gestión del patrimonio en reaccionar u otros marcos

[00:26:09] David: Esa, esa es una muy buena pregunta. Así que en lugar de hacernos cargo, ya sabes, queremos trabajar con, ya sabes, muchos desarrolladores sobre cómo están utilizando actualmente los estados. Creemos que esa es la parte que falta en la gestión de estados en la web en general.

Algo donde no tienes una tienda global. En primer lugar, la gestión, en lugar de tener almacenes locales aislados, se podría llamar que todos se comunican entre sí. Así que tener un marco de trabajo para eso, que es lo que xstate proporciona también la idea de efectos declarativos construidos en la biblioteca de gestión de estado.

Eso es algo que, ya sabes, los ejes también proporcionan y es algo donde queremos mostrar su utilidad en este momento. La forma en que los desarrolladores están haciendo estos efectos es muy ad hoc. No es algo que se pueda rastrear ni probar fácilmente. Así que tanto los efectos declarativos como la otra cosa que he mencionado son muy importantes para la gestión del estado, creemos, y también el hecho de ser completamente agnóstico al framework y eventualmente al lenguaje.

Estamos trabajando en xstate Python ahora mismo, y va a salir para otros lenguajes en los que básicamente podrías usar la misma definición de máquina en, ya sabes, cualquier marco, cualquier lenguaje, y todo va a funcionar exactamente igual. Así que creo que esas van a ser algunas características realmente asesinas para xstate y ya sabes, con suerte, ya sabes, otros marcos de gestión de estado pueden conseguir detrás de esas mismas ideas o ya sabes, podríamos, ya sabes, mostrar de alguna manera que xstate es correcto.

Una de las mejores soluciones para ello,

[00:27:43] Matías: Lo que has mencionado me lleva a dos preguntas más. Una es que dijiste que tendríamos más lenguajes y entonces podrías usar la misma declaración de máquina de estado en, a través del lenguaje. Eso significa que desde esta declaración de la máquina de estado es un objeto. En realidad puede ser un archivo JSON, ¿verdad?

[00:28:03] David: puede. 

[00:28:05] Matias: y entonces puedes simplemente compartir ese día, algún crecimiento de archivos. Y eso también significa que tal vez usted puede crear tipos de que JSON y la realidad sólo puede compartir los tipos como TypeScript. 

[00:28:17] David: Sí. 

[00:28:18] Matías: Eso es increíble. Es realmente útil. Y la segunda pregunta está relacionada con Tanner Linsley, el creador de react-query y Kent C Dodds. Son dos de los hombres más grandes, tal vez un líder de pensamiento acerca de los diferentes estados como UIs, estado, y el estado del servidor, donde X estado cae en estas dos categorías, o no hay categorías para cada estado.

[00:28:43] David: X que unifica a ambos. Así que, básicamente, una cosa de la que no creo que hayamos hablado demasiado es de los kilómetros de actor. Así que usted puede pensar en cada una de estas máquinas temáticas como la vida o como la definición del comportamiento de la única. Y así los actores se comunican enviándose mensajes. Y por cierto, el modelo de actor es realmente viejo también.

Creo que fue creado alrededor de 1973. Y así, cuando se piensa en los estados de la interfaz de usuario, como cada componente puede ser un actor. Y luego, cuando piensas en el estado del servidor, eso mismo puede ser un actor también. Así que la forma de orquestar la lógica entre la interfaz de usuario y el servidor es reducir el problema a sólo los actores que hablan con ellos.

Es un actor del servidor que habla con un actor de la interfaz de usuario, y luego podrías reemplazar ese actor del servidor con un actor falso si estás probando o un actor de socket web, o un trabajador web o algo más. Así que es realmente la independencia de la ubicación y la independencia de la implementación, porque es sólo una cosa que usted envía mensajes a.

Y así xstate, no trata de ser como una biblioteca para UI o una biblioteca para el servidor, el estado.

o una biblioteca para el flujo de trabajo. En su lugar, trata de destilar todas estas diferentes nociones de estados en sus partes más básicas, que son actores que se envían mensajes entre sí. 

[00:30:05] Matias: Y mencionaste el modelo de actor y la longevidad de eso, es una especie de tendencia que el desarrollo web está trayendo de vuelta algunas viejas prácticas de la ciencia de la computación que son la máquina de estado es muy viejo. El modelo de actor es muy antiguo. ¿Estamos reinventando la rueda?

[00:30:27] David: No, sólo estamos redescubriendo la rueda. Más bien, así que bueno, ¿qué, lo que creo que pasó es como la rueda?

son estos conceptos básicos de la ciencia de la computación. De hecho, se podría poner ya sabes, la inmutabilidad de la programación funcional en esa categoría y, ya sabes, sólo un montón de principios básicos que, o bien estamos utilizando todos los días o se han olvidado como que es todo parte de la rueda.

Y luego los desarrolladores como tendemos a hacer, queremos inventar ya sabes, más elegante. Eso, ya sabes, podría no, ya sabes, funcionar exactamente igual que una rueda. Y aquí estoy y muchos otros están tratando de decir, Hey, hay esta cosa llamada la rueda que se inventó hace décadas. Y lo que tenemos ahora es una especie de forma extraña.

No parece realmente una rueda. Ves que funciona. Dices que es más fácil de hacer, pero ¿adivina qué? La rueda ha sido probada durante muchas décadas. Vamos a intentar usar lo que ya funciona. Así que no vamos a reinventar nada. De hecho, sólo estamos volviendo a la antigua forma de hacer las cosas y haciéndolo lo más fielmente posible a lo que fueron las ideas originales. 

[00:31:36] Matías: Sí. Me gusta la idea de reutilizar lo que realmente se supone que sabemos. Y sí, porque es una especie de nuevo pero viejo. Estamos casi al final de este episodio, David y yo hemos sido perspicaces. Y por eso quiero preguntarte una especie de, un gran volumen. ¿Qué recomiendas a la audiencia? ¿Algo que quieras, algo que quieras compartir con ellos?

Más no, no tan tecnológico. Si quieres más como personal.

[00:32:07] David: bueno, yo, yo quiero compartir que vamos a estar llegando sí. Con algunos nuevos estados de la máquina de estado, nuestras herramientas como parte de la empresa. He mencionado Stately. Así que si usted va a stately.ai hay una lista de correo donde si usted se inscribe, usted será el primero en saber acerca de todas estas actualizaciones de la diversión.

No es una de esas listas de correo en las que se envía un email cada semana. Es más bien una vez cada dos meses o algo así. Así que sí. Compruébalo. Oh, también hago un montón de transmisiones en lo que llamamos los enmarcadores clave, que es una transmisión semanal en vivo donde traemos interfaces de usuario imaginativas a la vida.

Y también hacemos muchas cosas con máquinas de estado. Así que si quieres ver máquinas de estado usadas en la práctica, entonces echa un vistazo a los marcos clave. Sí. 

[00:32:54] Matias: Todas esas cosas se encontrarán en las notas del programa. Así que no te olvides de comprobarlo. David, ¿algo más que quieras decir para tus últimas palabras? Eso suena tan mortal, como, como para el show, como, no sé algún pensamiento.

[00:33:13] David: No, no puedo pensar en nada ahora, pero si alguno de sus oyentes. tiene alguna pregunta sobre el uso de máquinas de vapor en los gráficos de estado, en sus aplicaciones, entonces siempre estoy disponible en, ya sabes, Twitter github y nuestro discord en discord.gg/xstate. Así que por favor no dude en hablar conmigo. 

[00:33:33] Matias: Sí, que el discord es una muy buena adición. Así que y también parece que siempre estás en Twitter, así que sí. Sí. 

Eso es, gracias, David. Esto fue genial. episodio de Café con Tech. Por favor, revisa las notas del programa, sigue a David en Twitter. Puedes encontrarlo como David K piano, a la derecha.

Sí. Así que nos escuchamos en el próximo episodio


English

[00:00:00] Matias: Welcome back to another episode of cafe con tech in this special season today with me is David Khurshid or maybe mostly known as David K piano. The advocate of state machines. Hey David, thank you for coming to the show. 

[00:00:16] David: Hey, thank you very much. 

[00:00:17] Matias: We will, we'll talk about state machines and all of that concept in the webs and the web development.

But first of all, can you introduce yourself a little bit to the audience that, maybe not know you.

[00:00:31] David: sure. Yeah. My name is David . I've been a web developer. Thinking about 10 years now, I've been, you.

know, working everywhere from startups to most recently at Microsoft. And I actually just recently quit my job in Microsoft to go fully independent and then start my own thing. But yeah, I been also talking around the world, something that I miss very, very much and I hope to do so again, and the topics I love talking about are front end user interfaces, animations.

State machines in state charts. I'm also the creator of the library xstate, which is a library for creating state machines and state charts in JavaScript or TypeScript. 

[00:01:14] Matias: That's awesome. Can I ask you Did you already described somewhere else? What is your next step? Can you give us maybe a glimpse?

[00:01:23] David: Yeah, I actually didn't really say it explicitly. I just mentioned, I quit Microsoft and I gave sort of a few hints, but long story short I'm going to try to make xstate full like a full-time thing. And so basically starting a company behind it and offering some really useful tools and services for any web developer to create state machines and state charts, and also able to do it visually.

Analyze them and share them and collaborate. And I don't know, we have a whole lot of things planned. 

[00:01:59] Matias: Wow, that sounds amazing. So starting into the main topic here that is around all of your content and work at state machines, this is something I learned or kind of learned and during my bachelor degree and never. I hear about that anymore. Till recently related with UI implementations in web development

why is that? Why state machines kind of fall into the, into the cracks of development and then suddenly research as a solution for a big problem.

[00:02:36] David: It's actually a really interesting question because. Like you mentioned, state machines are usually taught in an academic setting where it's for I guess they're called deterministic, finite automatons, where you're using them for either implementing reg Xs or doing like, just sort of creating acceptors and things like that.

And so the bridge between that and actually using them for user interfaces and applications is not an obvious bridge, but State charts were created in 1989. And that sort of revealed how state machines can actually be used for things more then you know, what their academic setting implies that they're used for.

And Yeah, So when, when we think about like work flows and stuff like that, those are also obvious use cases where you could see, oh, I could actually use a state machine here or a state chart. And

[00:03:28] Matias: Yeah, it's so hard for a new commerce into the JavaScript development on UI to figure it out what the state machine are and why the hell you should use that if you have many other tools to handle your state. So I think that the first question that anyone should make is what, why is state is a problem that needs to be handle?

And what is a state.

[00:03:56] David: Sure. So when we talk about seeing machines, it really makes sense to talk about behaviors. First, when you're creating an application, it could be in a one of many behaviors. So for example, if you're trying to load data, then the loading of that data is a behavior and you might want to allow certain things to happen or forbid certain things from happening in that behavior.

And so when the data is finally loaded, that's a difference behavior. So by behaviors, I mean how your application is going to react to certain events. In fact, you could think of like, you. We have behaviors, for example, I could be sleeping or I could be awake and I react to different events depending on if I'm sleeping or awake.

And also I can't speak both sleeping and awake at the same time. So that's one of the key. Yeah. That's one of the key tenants of what the state machine is, is you can only be in one of a finite set of states at a time. So. 

[00:04:58] Matias: And trying to come back to another question. Why in the UI development state became such a problem that needed to complex solutions like a state machine to handle this state. Why UI development requires that kind of tools just to handle these slippers?

[00:05:19] David: Well, It's mostly because one word describing the aforementioned behaviors in our applications, they're not really explicit. so we, when we're making our applications, typically we do have a loading state and a success date. We might just have a Boolean variable that says is loading and we might think that that's fine.

Like, all we have to do is check the status of that is loading Boolean to see, okay, what should we do next? But the problem comes when you add more and more of those Boolean variables, like now is error, and then you have to check like, did the promise actually succeed? So you haven't is successfully in.

And so now you have to make sure that is loading. Isn't true at the same time that his success is true and multiplied this problem times like a hundred. As your app gets more complex and you start adding more features and you have to manage different things happening at the same time. Because applications, aren't just this big ball of functionality where a user could do anything at any given time applications have modes.

And so those modes are something that we clearly wants to separate into you know, different behaviors. So. It's clear what can happen in the app at any of those given modes. You know, for example, like if you have a machine and you know, you want to say, if I press this button, something should happen.

If the machine is off and obviously that button should do nothing. So instead of having a boolean that says is off or is on do this, then you just defined different modes in off mode, in. And then you define the behavior for each of those modes. And so, that's what state machines really helped with is organizing those states and those different modes.

[00:07:00] Matias: so, how a different mental model and in the UI development process? I think that when react came most of the people start fiddling around with the state because it's kind of natural in the framework and we set up flux, we set up Redux. In everything inside of that, eh, UI management estate, server state management, and several state management, all inside of that.

But what you described is a bit different. It's not just, it's like, I think that there is loading isError sample is really good because everyone can understand. But at the same time, it's really different of the mode that you are describing. Like it's. The collection of data collection or how you describe the state is different in react world.

How do you sort of define these states? Let me rephrase that. How did you came to the realization of creating X state to try to implement that in the current frameworks?

[00:08:05] David: so I started creating xstate. Actually it was one of my first jobs. We, we had like a big application where we had different metrics. Workflows and they were really, really complex. Like it was one of those big wizard forms where if you clicked one thing, then you might get different fields showing up and then you have to click the next step.

And then if you choose something different and go back, you have to handle a certain logic for that. It got really complex really quickly. So as a junior developer, I was trying to find what are some better patterns that I might not know of. That really helped me simplify this logic in the declarative.

Yeah. Because I I'm a visual learner, so I really want to see something where I could both visually diagram and implementing code. And so that's when I started learning about state machines and state charts. And when I looked into those, I realized like, you know, there are a few libraries about this, but none that are really like user or developer friendly, The frameworks that we're using every day, like angular and react and for good reason, because those frameworks sort of provide their own blessed state management ideas.

So like for example, angular provides RX reacts, provides its hooks. At the time it was like set state in sub UX provides that other stuff or yeah, Vue provides VueX. And so I want to create X date to create a truly framework agnostic a way for creating these state machines and state charts where we're not just considering the event, but we're considering both the finite state and the events. 

[00:09:36] Matias: What I feel this diffrent from how we used to develop a react application in particular that I am writing react is that you need to think about the all possible states. To define the state machine. And that obviously give you kind of a room of, to play. But the usual, the usual prospect is that you kind of run with what you have and then you add more things.

Then you add more, useState hooks and mute, and then suddenly you refactor and starting using a useReducer. And kind of trying to imitate the idea of a state that transition in between, but it's still short. So in react world in particular, how far is react from react utilities from 

state machines implementation. And because I know you develop another tool and kind of in the middle, the useEffect reducer, that I'm kind fan of it because really useful. But how far are we with the current tools on react or other frameworks, B two implementation of state machines and how we can move to that because developers that doesn't know about the machine at all, it's kind not teached anywhere.

[00:10:59] David: Yeah, And obviously we're trying to solve that by creating lots of educational materials and tutorials to let developers learn more about state machines since state charts. But as far as how far we are from that I, I would say that we're both pretty close and far at the same time with hooks react to introduce the concept or not the concept, but there's just the notion in reacts components of of both events based states.

Which is what use reducers for and declarative effects. The problem is that both of those are separated. So effects are run in the use effect, hook in response to some arbitrary piece of data changing. And that's not ideal. That's not really the way that we think as developers, we think like, okay, when this event happens, Do these acts or do these effects and then change the states.

We don't think like change this date and based on what changed, you know, run this effect, that's sort of implicit. And so that's why you mentioned use affect re reducer. That is a stepping stone to getting closer to the xtate model of both declarative effects and states based on events. So you're right.

Like the, the way to get closer to it is to actually use reducer because that's going to. Reinforced the mental model of sending events to change states. And from there it's actually a pretty short leap to go to to full on xstate. And so the useMachine hook in xstate react, it actually looks very close to use reducer.

So that reef factoring it is actually not that bad.

[00:12:32] Matias: Yeah, that is one of the fears of many developers around that is okay. I want to start using this new shiny tool that it's a complete makes sense for me, but I also need to teach that to them. Team and actually refactor things to make it work, how difficult could be that. Like I will take my current project and then I will start adding X state or more than, One question is how difficult could be refactored that in other question is what is kind of the best use case to sell many of X state into the.

[00:13:11] David: The difficulty for refactoring, it's actually not too difficult. And the reason is because X state works at the local level. First, if you want global state, just like Redux, you could easily just put X state they're called services, which are instances of machines. You could put that in use context and then just use it everywhere.

And you're also going to avoid a lot of those re rendering problems that you'll find with just putting any state in use contexts. So X they react is smarter about that, but anyway, the refactoring is just a you know, you do it bit by bit, so you could do it one component at a time, one small part of the app at a time until eventually everything is represented by X state.

And so the benefits you get from it, Are that number one? It's sometimes in fact it actually pretty often leads to shorter code because xstate has this object representation where a lot of the boiler plate code that you would have had to write for managing declarative effects and transitioning states and just organizing logic.

All of that is already built into the.

xstate model and the other biggest selling points. And this in fact was a selling point for me, for state charts was The visualizer. So the ability to visualize and inspect your state machines in real time as you're working on your app. And so that's, that's a huge value benefits to developments teams because now they don't have to pour through code and try to read it all and understand how it works.

Instead, they could just have a very clear visual of what the application logic is supposed to be and learning how to read a state diagram is not much of a learning curve because you're just following arrows. You're in a box. You follow the arrow now you're in a different box. So 

[00:14:59] Matias: Yeah. Since you mentioned that the following the state charts or state machine diagram is what kind of a skill a developer needs start fiddling and playing around with xstate. What is kind of the basic knowledge that you need to know to, to start working?

[00:15:18] David: Well, I think at, at first, like would have said that it was you, you have to have a good understanding of state machine since state. But honestly right now you just have to have a good understanding of use reducer. So the idea of changing state based on the Pence, because you could use X date as a much shorter use reducer and, you know, you could use it however you want.

Instead of like having to define all the finite states of fronts you could just use the machine with a single state and then edit the what's called context or extended. You, you can just edit that however you want. And then later go back and read factor. So that's the very beginning starting point.

And you know, it's, it's not much of a learning curve to get there. And then once you learn more concepts about state machines and state charts, then you could refactor your state machines to be more robust. 

[00:16:10] Matias: Do you mention a concept here? Machine that as far as I understand, is that a representation of the actual state machine that is performing the actions and managing events, but how can you kind of describe the concept of machine and what the machine does.

[00:16:28] David: So a machine you can think of as a reducer with rules. So if you think about your normal reducers that you create, whether you've used the used reducer hook or used Redux a reducer is typically like you have a big switch. And based on what events or they call it action. But what events comes in, you change the state based on that with machines, you add an extra layer to that.

So instead of basing it on the event, you base it on the states. So it's like, okay, am I in the loading states? All right. What are like now what events came in? So it goes date then events, and then you determine what next state is and what the action. For that state are, so that's the main difference there.

So you, you could think of a machine, basically the same as the reducer, but they reduced. So that also handles declarative actions or declarative effects really? 

[00:17:25] Matias: Yeah. And, and just to keeping the beginner mindset here you mentioned declarative effects. What are those and how that is different from just effects. Why are you naming these as declarative versus imperative? That I imagine that there's still that one.

[00:17:46] David: Yeah. Yeah. So declarative effects is just a way of saying this is the effects that should happen. So one.

difference like imperative effects would mean that as you're going through the function And trying to determine the next state, you're also executing those effects. There's absolutely no way to track them because you, know, effects are fire and forget once you've executed them, they're they're executed.

And the function, the return value of the function is just going to be that state. so you have no, and this is how for example, thunk, middleware and Redux works too. That reducers only return states. There's no indication of what effects should be executed. Declarative effects are basically a way of saying

here is an array of all the effects that should be executed by something. So without executing them, it's just a description of please execute this effect when you get the chance. So that's what the declarative effect is.

[00:18:44] Matias: And you, and so the state machine have these conservation. The concept event and the concept of declarative effect and all of the works together that effect the focus, trigger it or lunch when they have certain event happens. So that replaced the whole, the boiler plate and the complexity of use effect hook.

That is what value change when everybody's changed and all of that, that means that the declaration of the code to create the state machine can be. Long, right. Hard like writing. Yeah. The name of the event, the name of the transition, and then the, the effect that it needs to happen when it incision it happens. Is that complex or sounds weird when I say it.

[00:19:31] David: That's actually a common thoughts that oh, we're, we're just introducing a lot of complexity by making this big state machine definition. But in reality, it's not introducing complexity. It's just making the complexity that already exists. Very clear. We're not adding any additional complexity.

It's just a way of organizing like the different states and transitions that could happen in these single object structure. And like I mentioned earlier, xstate does use a in optics structure, but you could just abstract things into variables and functions and make that look a little bit cleaner. You could also, if you have a really big machine you could use what's called indications.

And so you could just invoke a different machine that contains encapsulated behavior. So you don't have to have one huge machine that tries to do everything

[00:20:22] Matias: you can have a machine of machines 

[00:20:25] David: Yeah. Yes. 

[00:20:26] Matias: complete composition through the end. The other thing I encounter when I was working with use reducer is the, sometimes the effect depends some, some. So you can act, you cannot actually move it out outside of the function to make it look cleaner because yes, that's the only reason why you want it to move it.

What happened here with X state? Can you, what have the effect that you want depends on some data that is, that belongs to the inside of the component

[00:21:00] David: so everything in xstate and, you know, state machines and state charts in general, everything works via sending events. That is the primary abstraction you're sending or receiving events. And that's basically how everything works in the, you know, state machine, state chart, actor model. So when some data changes from reacts, whether it's a prop change or something else, the machine needs to know about about it by receiving an events.

And so you would do that it's just a small use effects call where you could send events to the machine when that piece of data. Yes. 

[00:21:37] Matias: Makes sense and completely sense. What about debuggin and testing? The other pieces of every development process die, everything fails at some point. So how do you debug these different logic?

[00:21:49] David: So one of the beauties about state machines is that because everything is events, like I just talked about a debug or a testing just becomes replaying those eventos. So you're just like you would test any other reducer. You replay a set of events and ensure that you are in the states that you should be.

And because you also have the notion of declarative actions, you could also assert at any step of that process, that the correct actions are being triggered you know, in certain states and as far as debugging as well, you could you could insert log statements as actions. And, you know, you could just debug just like any other program, but also it being a state machine, you could also completely separated from the application and you could visualize what's going on and be able to check mistakes in the logic and see, oh, this transition, isn't where it should be.

It should actually be here and be able to verify that before running it in the app. 

[00:22:47] Matias: Yeah, that's, that's amazing to actually take all of the logic outside of the component of the UI thing. And then you can do anything you want with that. One thing that I forgot to ask is another concept that it ha it shows a lot is transition, right? It's not used at, among the other process or frameworks, but, so what is.

[00:23:13] David: A transition. Yeah. A change between states based on an event. So for example, if I'm sleeping, that's a state and it'd be events like the alarm clock going off happens. Now I'm in the awake state. So I transitioned from asleep to awake And I might do some actions or also the transition might have a, what's called a guard, which for example, if I'm in really deep sleep, like I'm really tired.

Then I might not transition to the wake state of the alarm goes off. I mean, hopefully I will. But yeah, so it's just a change in states based on an event. And it's always because of an events, that's how everything happens with, you know, state machines and state charts.

[00:23:56] Matias: And you can fire effects or, or other events in the transition process.

[00:24:02] David: Yes. Yes, you can. In fact, that's a, that's actually a really useful, I want to call it advanced technique of state machines And state charts, where if you receive a in events, you could also like send yourself in the event or you could send another machine in events and, you know, do things.

[00:24:19] Matias: And that's that that can help you orchestrate hard or complex workflows. 

[00:24:26] David: Yes. 

[00:24:27] Matias: What. What else is kind of missing from me about the X state content material. I know that you have some material on egghead. I know that there is the site with a lot of documentation. I know that there is a kind of a curated list of X state of machines are already ship at ready to use.

What else people can found by the way, all of that in the show notes.

[00:24:52] David: Yeah. So on X date the documentation, there are resources where there's hundreds of resources written by other people about you know, just how to make machines and how to use xstate in your applications. There's also a really good resource called xstate, desk catalog. Dot com. And so that contains a collection of very useful machines that you could visualize at the same time.

As you're reading through the documentation, we're also we're also creating a lot of tutorials and examples that are going to be in the repository. So trust me, a lot of educational material is coming up. 

[00:25:27] Matias: Okay. Yeah, I know for sure. And that's always a helpful but in the state management world, that is, I'm not sure if what happens in other frameworks, but at least in react is kind of a big, big problem and concept that everyone discussed. X state is easily in a little corner of the entire thing. Like people are always talking about redux still contexts and other tools like SWR or react-query.

So how can S X state somehow take over the estate management problem in react or other frameworks

[00:26:09] David: That, that that's a really good question. So instead of taking over, you know, we wants to work with, you know, a lot of developers on how they're currently using states. So we believe like that's the, the missing part of state management's just in the you know, in, in the web in general.

Something where you don't have a global store. First, the management, instead you have local isolated stores, you could call it That all communicate with each other. So having a framework for that, which is what xstate provides also the idea of declarative effects built into the state management library.

That's something that, you know, axes also provides and it's something where we want to show off its usefulness right now. The way that developers are doing these effects is it's very ad hoc. It's not something that you could easily track nor easily test. And so both those like declarative effects and you know, the other thing I mentioned those are very important to state management, we believe, and also just being completely framework agnostic and eventually language agnostic.

We're working on xstate Python right now, and it's going to be coming out for other languages where you could basically use that same machine definition in, you know, any framework, any language, and it's all going to work exactly the same. So I think that those are going to be some really killer features for xstate and you know, hopefully, you know, other state management frameworks can get behind those same ideas or you know, we could, you know, show somehow that xstate is right.

One of the best solutions for that,

[00:27:43] Matias: That what you mentioned brings me to two more questions. One is you said that we'll have more languages and then you can actually use the same state machine declaration into, across the language. That means that since this state machine declaration is an object. It can actually be a JSON file, right?

[00:28:03] David: it can. 

[00:28:05] Matias: and then you can just share that day, some file growth. And that also means that maybe you can create types from that JSON and the actually you can just share the types like TypeScript. 

[00:28:17] David: Yes. 

[00:28:18] Matias: That's amazing. That's really useful. And the second question is related with Tanner Linsley, the creator fo react-query and Kent C Dodds. Are two of the bigger men, maybe a thought leader about the different states like UIs, state, and server state, where X state falls into these two categories, or there are no categories for each state.

[00:28:43] David: X that unifies both of them. So it basically one thing that I don't think we talked too much about is the actor miles. So you can think of each of these themed machines as living or as defining the behavior of single. And so actors communicate by sending each other messages. And by the way, the actor model is really old as well, too.

I think it was created around 1973. And so when you think about UI states, like each components can be an actor. And then when you think about server state, that itself can be an actor as well. So the way that you orchestrate logic between the UI and the server is you reduce the problem to just actors talking to them.

It's a server actor talking to a UI actor, and then you could replace that server actor with maybe a mock actor if you're testing or a web socket actor, or a web worker or something else. So it's really location independence and implementation independence, because it's just a thing that you send messages to.

And so xstate, doesn't try to be like a library for UI or a library for server, state.

or a library for workflow. It instead tries to distill all of these different notions of states down into into its most basic parts, which is actors sending messages to each other. 

[00:30:05] Matias: And you mentioned the actor model and the longevity of that, it's kind of a trend that the web development is bringing back some old practices from computer science that are the state machine is really old. The, actor model is really old. Are we reinventing the wheel?

[00:30:27] David: No, we are just rediscovering the wheel. More like, so well, what, what I think happened is like the wheel?

is these basic concepts of computer science. In fact, you could put you know, functional programming immutability into that category and, you know, just a lot of basic principles that either we're using everyday or have been forgotten like that's all part of the wheel.

And then developers as we tend to do, we wants to invent you know, fancier. That's, you know, might not, you know, function exactly the same as a wheel. And so here I am and many others are trying to say, Hey, there's this thing called the wheel that was invented decades ago. And what we have right now is sort of a weird shape.

Doesn't really look like a wheel. You see it works. You say it's easier to make, but guess what? The wheel has been tried and tested for many decades. Let's try using what already works for you. So we're not reinventing anything. In fact, we're just going back to the old way of doing things and doing so as faithfully as we can, to what the original ideas were. 

[00:31:36] Matias: Yeah. I like the idea of reusing what we are really supposed to know. And yeah, because it's kind of a kind of new but old. We are almost at the end of this episode, David and I it's been insightful. And so I want to ask you kind of a, a big volume. What do you recommend to the audience? Anything that you would want, something that you want to share with them?

More more, not, not so techie. If you want more like personal.

[00:32:07] David: well, I, I do want to share that we are going to be coming up yeah. With some new state machine states, our tools as part of the company. I mentioned stately. So if you go to stately.ai there's a mailing list where if you sign up, you'll be the first to know about all of these fun updates.

It's not one of those mailing lists where it's in an email every week. It's more like once every couple months or something. So yeah. Check that out. Oh, also I I do a lot of streams on what we call the key framers, which is a weekly live stream where we bring imaginative user interfaces to life.

And we do do a lot of things with state machines as well. So if you want to see state machines used in practice, then check out the key framers. Yeah. 

[00:32:54] Matias: All of that things will be found in the show notes. So don't forget to check that out. David, anything else you want to kind of say for your last words? That sounds so deadly, like, like for the show, like, I don't know some thought.

[00:33:13] David: No, I can't think of anything now, but if any of your listeners. Ever have any questions about using steam machines in state charts, in their applications, then I'm always available on, you know, Twitter github and our discord at discord.gg/xstate. So please feel free to talk to me. 

[00:33:33] Matias: Yeah, that the discord is a really good addition. So and also looks like you're always in Twitter, so yeah. Yeah. 

That's that's Thank you, David. This was cool. episode of Café con Tech. Please check the out show notes, follow David in Twitter. You can find him as David K piano, right.

Yeah. So we hear us in the next episode