Una FSM en código, sin librería

Existe la superstición de que trabajar con máquinas de estado exige adoptar una librería pesada. Es falso, y creerlo te aleja del modelo justo cuando más te conviene entenderlo. Una FSM es una función pura de estado y evento a estado: cabe en un switch, cabe en un objeto, cabe en la cabeza. Antes de instalar nada, quiero que la escribas a mano hasta que la mecánica te resulte transparente, porque solo así sabrás qué te está dando de verdad una librería el día que la necesites —y qué te estaba dando gratis el lenguaje desde el principio—.

El switch: la FSM más honesta

La forma más directa de escribir δ es un switch anidado: por fuera ramificas según el estado, por dentro según el evento. Es verbosa, pero no esconde nada: cada transición es una línea que puedes leer y verificar.

type Estado = "idle" | "loading" | "success" | "error"
type Evento = { type: "FETCH" } | { type: "RESOLVE" } | { type: "REJECT" } | { type: "RETRY" }

function transicion(estado: Estado, evento: Evento): Estado {
  switch (estado) {
    case "idle":
      return evento.type === "FETCH" ? "loading" : estado
    case "loading":
      if (evento.type === "RESOLVE") return "success"
      if (evento.type === "REJECT") return "error"
      return estado
    case "error":
      return evento.type === "RETRY" ? "loading" : estado
    case "success":
      return estado   // estado terminal: ningun evento lo mueve
  }
}

Cada return estado es una celda vacía de la tabla hecha código: el evento inaplicable devuelve el estado sin cambios, la política de ignorado silencioso del nivel anterior. Cero dependencias, cero magia, y el compilador exige que trates cada estado en el switch. Para una máquina pequeña, esto es difícil de mejorar.

El objeto de transiciones: datos, no código

Cuando la máquina crece, el switch se vuelve ruidoso. La alternativa es dirigir por datos: la tabla como objeto, y una función diminuta que la consulta. La lógica de transición deja de ser código y pasa a ser una estructura que puedes serializar, visualizar o generar.

const maquina = {
  inicial: "idle" as const,
  estados: {
    idle:    { on: { FETCH: "loading" } },
    loading: { on: { RESOLVE: "success", REJECT: "error" }, entry: () => log("cargando...") },
    success: { on: {} },
    error:   { on: { RETRY: "loading" } },
  },
}

function enviar(estado: string, tipo: string) {
  const destino = maquina.estados[estado]?.on?.[tipo] ?? estado   // sin transicion = quieto
  if (destino !== estado) maquina.estados[destino]?.entry?.()      // accion de entrada estilo Moore
  return destino
}

Con quince líneas ya tienes estados, transiciones y acciones de entrada al estilo Moore —el efecto se dispara al ENTRAR en el estado, no en la transición—. Añadir una guarda es trivial: en lugar de que la celda sea un string, que sea un objeto con destino y una función cond que decide si la transición procede. Con eso cubres el noventa por ciento de las máquinas que una interfaz necesita.

Una función de transición pura no tiene vida propia: para animarla necesitas un envoltorio mínimo que guarde el estado actual y avise a quien escuche. Ese envoltorio son otras diez líneas, y con ellas la máquina se convierte en un store observable completo.

function crearMaquina(inicial: Estado) {
  let estado = inicial
  const oyentes = new Set<(e: Estado) => void>()
  return {
    get: () => estado,
    enviar(evento: Evento) {
      estado = transicion(estado, evento)   // aplica delta
      oyentes.forEach((f) => f(estado))      // notifica a los suscriptores
    },
    suscribir(f: (e: Estado) => void) {
      oyentes.add(f)
      return () => oyentes.delete(f)          // devuelve el cancelador
    },
  }
}

Con eso tienes get para leer, enviar para transicionar y suscribir para reaccionar: el contrato exacto que expone cualquier motor, reducido a su esencia. Si te suena a los signals y al patrón observer de los niveles 3 y 4, es porque lo es. Una máquina de estados no es más que un store cuya escritura está restringida a transiciones legales: le quitas al store la libertad de aceptar cualquier valor y le impones la disciplina de δ.

La frontera: qué justifica un motor

A mano llegas lejos: estados finitos, transiciones, acciones de entrada y salida, y guardas con un poco más de código. El diagrama siguiente resume la máquina completa que acabamos de construir sin instalar nada.

stateDiagram-v2
[*] --> idle
idle --> loading : FETCH
loading --> success : RESOLVE
loading --> error : REJECT
error --> loading : RETRY

Incluso una guarda —una transición condicionada— cabe a mano: basta con que la celda deje de ser un destino fijo y pase a ser una función que mira el contexto y decide. Con eso cubres el reintento con límite de intentos sin instalar nada.

const conGuarda = {
  error: {
    on: {
      RETRY: (ctx: { intentos: number }) =>
        ctx.intentos < 3 ? "loading" : "error",   // guarda: solo si quedan intentos
    },
  },
}

El día que necesitas encadenar varias guardas, contextos ricos y tipados, o que la condición dependa de datos que evolucionan por su cuenta, el código a mano empieza a pedir estructura a gritos. Ese es el primer aviso de que un motor te ahorraría más de lo que te cuesta.

Lo que NO obtienes barato a mano es todo lo que empieza donde acaba esta lección: jerarquía de estados anidados, regiones paralelas ortogonales, transiciones diferidas por tiempo, invocación y generación de actores, historia, y —nada menor— visualización y herramientas de depuración con viaje en el tiempo. Cada una de esas piezas la puedes emular con esfuerzo, pero reimplementarlas bien es reescribir una librería. Ese es el punto exacto en el que delegar tiene sentido.