La ontología de las máquinas de estado
El mapa mental de las máquinas: autómatas finitos, statecharts de Harel, XState v5, el actor model, testing basado en modelos y los patrones reales.
Hay una clase entera de bugs que desaparece cuando dejas de representar el estado con booleanos sueltos. Si tu pantalla tiene cargando, error y datos como tres variables independientes, el sistema de tipos te permite construir la combinación absurda de estar cargando y con error a la vez. Una máquina de estado hace esa combinación literalmente inexpresable: solo existen los estados que declaras y solo se llega a ellos por las transiciones que permites. Este mapa te da la visión aérea del territorio, de la teoría de autómatas a XState en producción.
- Ver el mapa mental completo de las máquinas de estado.
- Entender qué añaden los statecharts sobre las FSM clásicas.
- Situar XState v5, el actor model y el testing basado en modelos.
- Empezar con el criterio correcto sobre cuándo modelar con máquinas.
El territorio, de un vistazo
mindmap
root((Maquinas de estado))
Teoria
Automatas finitos
DFA y NFA
Mealy y Moore
SCXML
Statecharts
Jerarquia
Paralelismo
Historia
Estados finales
XState
setup y tipos
context y guards
actions
invoke y actores
Practica
Maquinas en la UI
Testing y cobertura
Visualizar
Datos y servidor
Patrones
Wizards
Media
Auth
BackendLas ideas clave
Los estados imposibles no existen
Una máquina declara el conjunto finito de situaciones válidas. No hay que “acordarse” de resetear un booleano: si no hay transición hacia un estado, no se puede llegar a él. El modelo es la validación.
Los statecharts domestican la explosión
Las FSM planas se vuelven inmanejables cuando hay varias dimensiones. Harel añadió jerarquía, regiones paralelas e historia: la misma expresividad con una fracción de los estados.
El actor es la unidad
XState v5 gira alrededor de actores: entidades vivas y aisladas que se comunican por mensajes. Una máquina es un tipo de actor, y componer sistemas es hacer que hablen entre sí.
El diagrama ES el código
Un statechart se puede dibujar, y ese dibujo no es documentación que envejece: es una vista del mismo modelo que ejecuta la app. Diseño, producto e ingeniería miran lo mismo.
Por qué importa
Es tentador reducir este tema a “aprender XState”, y es justo lo contrario. Lo que se aprende aquí es una disciplina de modelado que puedes aplicar con una librería, con un switch de veinte líneas, o con un enum de Swift o Rust. La pregunta que enseña una máquina de estado es sencilla y demoledora: ¿en qué situaciones puede estar realmente esto, y cómo se pasa de una a otra? Casi ningún componente de UI se escribe respondiendo a esa pregunta; se escriben añadiendo un booleano cada vez que aparece un caso nuevo, hasta que nadie sabe qué combinaciones son posibles. El resultado son los bugs más caros de reproducir: el botón que se queda deshabilitado, el spinner eterno, el modal que se abre sobre otro. Una máquina convierte ese caos implícito en un artefacto explícito que puedes leer, dibujar, revisar con tu equipo y recorrer exhaustivamente en un test. Y ahí está el pago mayor: si el modelo enumera los estados y las transiciones, un generador puede visitarlos todos y producir casos de prueba que tú nunca habrías escrito a mano. La contrapartida es honesta: modelar cuesta más al principio y es sobreingeniería para un contador. El criterio, que este track persigue sin descanso, es saber exactamente cuándo ese coste se paga solo.
El camino
- Niveles 1–8 · Fundamentos — FSM, statecharts, XState (modelo, context, actores, efectos), máquinas en la UI y el criterio.
- Niveles 9–10 · Teoría — autómatas finitos, lenguajes regulares, Mealy/Moore y la semántica formal de SCXML.
- Niveles 11–13 · XState a fondo —
setupy tipos, jerarquía y paralelismo, historia, estados finales y output. - Niveles 14–16 · Práctica — testing y model-based testing, visualización, y la relación con el estado del servidor.
- Niveles 17–21 · Patrones — backend y workflows, wizards, media, auth y actores distribuidos.
- Niveles 22–25 · Maestría — alternativas a XState, máquinas en otros lenguajes, rendimiento y la síntesis final.
- Toma un componente que hayas escrito con dos o más booleanos de estado y escribe la lista de combinaciones posibles.
- Marca cuáles de esas combinaciones son absurdas. Cada una es un bug esperando su turno.
- Reescribe esa lista como un conjunto de estados con nombre y dibuja las flechas entre ellos. Acabas de hacer tu primera máquina.
- Comprométete con la pregunta: en qué situaciones puede estar esto, y cómo se pasa de una a otra.