createMachine: la anatomía de una máquina

Casi todo bug de estado nace de la misma raíz: representamos una situación con varias banderas booleanas independientes y confiamos —sin garantía— en que jamás aparezca una combinación imposible. cargando y error a true a la vez; enviado sin datos; un formulario a la vez limpio y sucio. Una máquina de estados finitos ataca el problema por debajo: en lugar de banderas que se combinan libremente, declaras un conjunto cerrado y explícito de estados y las únicas transiciones legales entre ellos. createMachine es el constructor de esa declaración en XState v5. No ejecuta nada todavía: produce un valor puro que describe un autómata, y esa descripción es a la vez el modelo mental, la documentación y el código ejecutable.

Del booleano al estado explícito

Cuatro banderas booleanas describen dieciséis combinaciones. La mayoría no significan nada: cargando con error, exito con vacio. El código que las usa acaba lleno de condicionales defensivos que intentan reconstruir, a posteriori, cuál de esas dieciséis combinaciones es la “de verdad”. El espacio de estados creció como 2 elevado a n, pero solo un puñado de puntos de ese espacio son legales.

// Cuatro banderas: dieciseis combinaciones, casi todas ilegales
let cargando = false
let error = false
let exito = false
let vacio = false
// nada en el sistema de tipos impide cargando y error a la vez

Una máquina de estados finitos invierte la lógica: no enumera lo que puede combinarse, sino lo que puede ocurrir. Formalmente es una quíntupla —un conjunto de estados, un alfabeto de eventos, una función de transición, un estado inicial y un conjunto de estados finales—. El espacio deja de ser 2 elevado a n y pasa a ser exactamente los estados que tú nombraste. Lo imposible no se comprueba en tiempo de ejecución: es inexpresable.

La pieza que hace el trabajo es la función de transición. En la teoría se escribe como una función que, dado un estado y un símbolo del alfabeto, devuelve el estado siguiente. En una máquina bien diseñada esa función es parcial a propósito: no todos los pares de estado y evento tienen imagen. Cuando un par no está definido, el evento no produce transición, y esa ausencia es una decisión de diseño tan deliberada como cualquier flecha dibujada.

Esa parcialidad deliberada es la diferencia entre permitir y prohibir. Un modelo que solo admite lo declarado es más fácil de razonar que uno que rechaza lo indeseado: el conjunto de lo permitido es finito y está a la vista, mientras que el de lo indeseado es abierto e inagotable. Enumerar lo posible acota el sistema; intentar enumerar lo imposible no termina nunca.

createMachine: las cuatro piezas

createMachine recibe un único objeto de configuración. En su forma mínima aparecen cuatro claves: id, un nombre para la máquina; initial, el estado en el que arranca; states, el mapa de todos los estados posibles; y, dentro de cada estado, on, el mapa de las transiciones que ese estado admite.

import { createMachine } from 'xstate'

const alternador = createMachine({
  id: 'alternador',
  initial: 'inactivo',
  states: {
    inactivo: {
      on: { ALTERNAR: 'activo' },
    },
    activo: {
      on: { ALTERNAR: 'inactivo' },
    },
  },
})

Léelo como lo que es: un autómata de dos estados. Arranca en inactivo. Estando inactivo, el evento ALTERNAR lo lleva a activo; estando activo, el mismo evento lo devuelve a inactivo. No hay una tercera situación posible, y no existe ningún evento capaz de crear una. El estado ya no es una conjunción de banderas: es una única variable con un dominio cerrado.

Las transiciones viven en on

El bloque on de un estado es, literalmente, la función de transición restringida a ese estado: dada la situación actual y un evento, devuelve la situación siguiente. En su forma más corta, cada entrada mapea el type de un evento al nombre del estado destino. Lo revelador es lo que NO aparece: si un estado no declara una entrada on para cierto evento, ese evento simplemente no produce ningún efecto en ese estado. La transición ilegal no se rechaza con un if; es imposible por omisión.

stateDiagram-v2
[*] --> inactivo
inactivo --> activo: ALTERNAR
activo --> inactivo: ALTERNAR

Esa asimetría es la clave pedagógica de la lección. En el modelo de banderas, para prohibir una transición hay que escribir código que la impida. En el modelo de máquina, para permitir una transición hay que declararla; todo lo no declarado está prohibido por defecto. El diseño pasa de una lista negra frágil a una lista blanca exhaustiva, y esa exhaustividad es la que un revisor humano —o una herramienta— puede auditar de un vistazo.

Y como la declaración es exhaustiva, se puede verificar de forma mecánica: dado el conjunto de estados y el de eventos, comprobar qué pares tienen transición y cuáles no es un recorrido finito. Esa tabla completa es, ni más ni menos, la especificación del comportamiento, y es también lo que permitirá dibujar la máquina y probarla sin ejecutarla en las lecciones siguientes.

Un ejemplo menos de juguete: una petición de datos, el caso que abría la lección con banderas, modelado ahora como cuatro estados entre los que no cabe ninguna combinación.

const datos = createMachine({
  id: 'datos',
  initial: 'inactivo',
  states: {
    inactivo: {
      on: { CARGAR: 'cargando' },
    },
    cargando: {
      on: {
        EXITO: 'exito',
        ERROR: 'fallo',
      },
    },
    exito: {
      on: { CARGAR: 'cargando' },
    },
    fallo: {
      on: { REINTENTAR: 'cargando' },
    },
  },
})

Las dieciséis combinaciones del principio se han reducido a cuatro estados nombrados. No existe forma de estar cargando y en fallo a la vez, porque el estado es uno solo; el bug más común de las peticiones asíncronas desaparece por construcción, no por vigilancia. Y el estado cargando solo puede alcanzarse desde inactivo, exito o fallo mediante un evento explícito, nunca por accidente.

Transiciones globales: el on de la máquina

A veces un evento debe atenderse en cualquier estado: una avería, un cierre de sesión, un reinicio de emergencia. Repetir esa transición en cada estado sería ruido y una fuente de olvidos —basta añadir un estado nuevo y olvidar copiarla para abrir un agujero—. Para eso, createMachine admite un bloque on en el nivel superior, hermano de states: las transiciones que declares ahí aplican con independencia del estado en que se encuentre la máquina.

const alternador = createMachine({
  id: 'alternador',
  initial: 'inactivo',
  states: {
    inactivo: { on: { ALTERNAR: 'activo' } },
    activo: { on: { ALTERNAR: 'inactivo' } },
    intermitente: {},
  },
  on: {
    AVERIA: '.intermitente',   // desde cualquier estado
  },
})

Fíjate en el destino .intermitente, con punto inicial: el punto indica un destino relativo a la raíz de la máquina, es decir, su hijo intermitente. Con esta pieza la anatomía queda completa —id, initial, states y los dos niveles de on, el local de cada estado y el global de la máquina—. El on de nivel superior es la contrapartida de la factorización jerárquica que verás en la lección siguiente: en lugar de subir la transición a un ancestro intermedio, la eleva hasta la raíz, donde alcanza a todo el autómata sin excepción.