La FSM a mano: veinte líneas y cero dependencias

Un nivel titulado alternativas a XState solo puede empezar de una manera: fijando el precio del suelo. Antes de comparar motores conviene saber exactamente cuánto cuesta no usar ninguno, y la respuesta incomoda a los dos bandos: unas veinte líneas de TypeScript que el compilador vigila mejor de lo que vigilaría cualquier objeto de configuración. Lo que sigue no es minimalismo nostálgico ni provocación; es la línea base contra la que se mide todo lo demás en las cuatro lecciones siguientes. Cada dependencia que instales a partir de aquí tendrá que justificarse contra este código —no contra el caos de booleanos correlacionados que ya diste por superado en el nivel uno— y esa comparación exigente es justamente la que casi nadie hace.

Dos escrituras de la misma función

Formalmente, δ es una función parcial de S × Σ en S. A mano tienes dos maneras de materializarla, y la elección entre ellas no es estilística: decide qué puede hacer el resto del sistema con tu máquina. La primera la escribe como código, ramificando primero por estado y después por evento.

type Estado = 'inactivo' | 'cargando' | 'listo' | 'fallo'
type Evento = { type: 'PEDIR' } | { type: 'RESOLVER' } | { type: 'RECHAZAR' } | { type: 'REINTENTAR' }

function imposible(x: never): never {
  throw new Error(`estado no cubierto: ${String(x)}`)
}

export function transicion(estado: Estado, evento: Evento): Estado {
  switch (estado) {
    case 'inactivo':  return evento.type === 'PEDIR' ? 'cargando' : estado
    case 'cargando':  return evento.type === 'RESOLVER' ? 'listo' : evento.type === 'RECHAZAR' ? 'fallo' : estado
    case 'listo':     return evento.type === 'PEDIR' ? 'cargando' : estado
    case 'fallo':     return evento.type === 'REINTENTAR' ? 'cargando' : estado
    default:          return imposible(estado)
  }
}

La rama default con el parámetro never no es adorno: convierte al compilador en un verificador de totalidad. El día que añadas un quinto estado al tipo, esa línea deja de compilar y te obliga a decidir qué hace la máquina en él. Ningún motor te da esa garantía en tiempo de compilación con esta contundencia, porque en un objeto de configuración los estados son claves de datos y no ramas que el analizador de flujo pueda contar.

La segunda escritura convierte δ en dato: un objeto donde cada celda existente es una transición legal y cada celda ausente es un evento ignorado.

type Tabla = Record<Estado, Partial<Record<Evento['type'], Estado>>>

export const tabla = {
  inactivo: { PEDIR: 'cargando' },
  cargando: { RESOLVER: 'listo', RECHAZAR: 'fallo' },
  listo:    { PEDIR: 'cargando' },
  fallo:    { REINTENTAR: 'cargando' },
} satisfies Tabla

La diferencia entre ambas es exactamente la que separa a las librerías ligeras de los motores completos, y por eso conviene entenderla aquí, en pequeño. El switch es opaco: solo se puede ejecutar. La tabla es transparente: se puede ejecutar, recorrer, serializar, dibujar, difundir en un control de cambios y comparar entre dos versiones del código. La propiedad que hace posible el diagrama que es el código no la aporta ninguna librería; la aporta haber escrito la definición como estructura y no como control de flujo.

Lo que cabe en veinte líneas

El escepticismo habitual sostiene que a mano solo se llega a lo trivial. Es falso, y comprobarlo importa: guardas, acciones de entrada y suscripción caben sin despeinarse en un intérprete diminuto.

type Celda = Estado | { destino: Estado; cond?: (ctx: Ctx) => boolean }
type Ctx = { intentos: number }

export function crearMaquina(inicial: Estado, ctx: Ctx) {
  let estado = inicial
  const oyentes = new Set<(e: Estado) => void>()
  const entrada: Partial<Record<Estado, (c: Ctx) => void>> = {
    cargando: (c) => { c.intentos += 1 },
  }
  return {
    get estado() { return estado },
    enviar(tipo: Evento['type']) {
      const celda = (tabla as Record<Estado, Record<string, Celda>>)[estado][tipo]
      if (!celda) return estado                                   // evento inaplicable: quieto
      const destino = typeof celda === 'string' ? celda : celda.destino
      if (typeof celda !== 'string' && celda.cond && !celda.cond(ctx)) return estado
      estado = destino
      entrada[estado]?.(ctx)                                      // accion de entrada estilo Moore
      oyentes.forEach((f) => f(estado))
      return estado
    },
    suscribir(f: (e: Estado) => void) { oyentes.add(f); return () => oyentes.delete(f) },
  }
}

stateDiagram-v2
[*] --> inactivo
inactivo --> cargando : PEDIR
cargando --> listo : RESOLVER
cargando --> fallo : RECHAZAR
listo --> cargando : PEDIR
fallo --> cargando : REINTENTAR

Que la definición sea dato paga su primer dividendo en las pruebas. Con quince líneas más recorres el grafo en anchura y detectas estados inalcanzables, que son el defecto de modelado más frecuente y el más invisible: nadie escribe un test para un estado al que nunca se llega.

export function alcanzables(t: Tabla, inicial: Estado): Set<Estado> {
  const vistos = new Set<Estado>([inicial])
  const cola: Estado[] = [inicial]
  while (cola.length > 0) {
    const actual = cola.shift() as Estado
    for (const destino of Object.values(t[actual]) as Estado[]) {
      if (!vistos.has(destino)) { vistos.add(destino); cola.push(destino) }
    }
  }
  return vistos                                  // compara con Object.keys de la tabla
}

El techo, medido en ausencias

Un techo honesto se enumera, no se insinúa. Estas son las capacidades que a mano cuestan mucho más de lo que ahorran, y ninguna de ellas aparece hasta que tu problema la pide de verdad.

Las tres primeras filas son las que marcan la frontera real. Emular jerarquía a mano significa reimplementar el algoritmo de resolución de transiciones que estudiaste al hablar de semántica formal, incluida la selección del descriptor más profundo y el orden de salidas y entradas. Emular regiones paralelas significa aceptar el producto cartesiano de estados que Harel vino a eliminar. En cuanto una de esas dos aparece, el código a mano deja de ser una alternativa barata y se convierte en un motor mal escrito por ti.

Hay además un coste que no cabe en la tabla porque no es técnico sino social: el segundo lector. Tu intérprete de veinte líneas es transparente para ti y ligeramente ajeno para cualquier otra persona, que tendrá que leerlo entero antes de tocar una transición. Un motor conocido traslada ese coste a documentación pública y conocimiento previo. La pregunta no es si tu código es bueno, sino cuántas personas van a tener que entenderlo y cuántas veces.