Actor logics: envolver cualquier asincronía

La lección anterior mostró que invoke ata un actor a un estado, pero dejó una pregunta abierta: ¿de qué está hecho un actor? La respuesta separa dos conceptos que el modelo de actores mantiene deliberadamente distintos. Una cosa es la identidad —el buzón, el id, el lugar en el sistema— y otra la lógica de actor: la receta que dicta cómo esa entidad procesa el tiempo, produce valores y responde a los mensajes. XState v5 estandariza esa receta con cuatro constructores, cada uno pensado para una forma concreta de asincronía. No son cuatro atajos arbitrarios: son una taxonomía casi exhaustiva de cómo el mundo exterior entrega información a un programa —de golpe, en goteo, por empuje o por reducción— y aprender a mapear cada efecto real al creador correcto es lo que convierte a XState en un orquestador universal de lo asíncrono.

Identidad y lógica: dos ejes independientes

En el modelo de actores, un actor es una entidad con un buzón que procesa mensajes uno a uno. Pero cómo los procesa —qué hace al recibirlos, qué emite, cuándo termina— no forma parte de la identidad: es su lógica. XState materializa esta separación con la función createActor, que toma una lógica y le da vida como instancia. Los cuatro creadores from* producen justamente lógicas; invoke y spawn les dan identidad dentro de una máquina.

La ventaja de separar ambos ejes es la componibilidad. La misma lógica puede instanciarse muchas veces con distintos input, probarse de forma aislada sin máquina alguna, o intercambiarse por un doble en los tests. La lógica es un valor puro y reutilizable; la identidad es lo que la ancla en un sistema concreto.

El valor único y el flujo: fromPromise y fromObservable

fromPromise es el creador más común. Recibe una función asíncrona y produce una lógica que, al arrancar, ejecuta la promesa. Cuando resuelve, el actor termina y su valor viaja al padre como el output del evento de finalización. Cuando rechaza, termina en error y el padre lo recibe por onError. Un detalle crucial de v5: la función recibe un signal, un AbortSignal que el runtime dispara si el actor se detiene antes de resolver, lo que permite cancelar la petición subyacente.

import { fromPromise } from 'xstate'

const cargarUsuario = fromPromise(
  async ({ input, signal }: { input: { id: string }; signal: AbortSignal }) => {
    const res = await fetch(`/api/users/${input.id}`, { signal })
    if (!res.ok) throw new Error(`HTTP ${res.status}`)
    return (await res.json()) as Usuario
  },
)

fromObservable cubre el caso en que la fuente no entrega un valor, sino muchos a lo largo del tiempo. Envuelve cualquier observable —de RxJS o compatible— y el actor emite una instantánea por cada valor. El padre reacciona a esas emisiones con onSnapshot, y onDone se dispara solo si el observable completa. Es la vía natural para relojes, streams de posición, o cualquier telemetría continua.

import { fromObservable } from 'xstate'
import { interval, map } from 'rxjs'

const reloj = fromObservable(({ input }: { input: { periodo: number } }) =>
  interval(input.periodo).pipe(map((n) => ({ tick: n }))),
)

La fuente imperativa y el reductor: fromCallback y fromTransition

fromCallback es la válvula de escape para todo lo que no encaja en una promesa ni en un observable: APIs imperativas, bidireccionales, con suscripción y limpieza manual. Su función recibe sendBack para emitir eventos al padre y receive para escuchar los que el padre le dirija; lo que retorna es la función de limpieza que el runtime ejecutará al detener el actor. Es el creador con el que se envuelven WebSockets, EventSource o listeners del DOM.

import { fromCallback } from 'xstate'

const socket = fromCallback(
  ({ sendBack, receive, input }: { input: { url: string } }) => {
    const ws = new WebSocket(input.url)
    ws.onmessage = (e) => sendBack({ type: 'MENSAJE', datos: e.data })
    ws.onerror = () => sendBack({ type: 'CAIDA' })
    receive((evento) => {
      if (evento.type === 'ENVIAR') ws.send(evento.payload)
    })
    return () => ws.close()
  },
)

fromTransition es el más peculiar: convierte una función reductora pura en un actor. Recibe la reducción estado, evento y el estado inicial, y produce un actor cuyo estado interno evoluciona con cada evento que le llegue, exponiéndolo como instantánea. Es, en esencia, un store de Redux instanciable como actor, útil para encapsular una porción de lógica de reducción reutilizable dentro del sistema.

import { fromTransition } from 'xstate'

const contador = fromTransition(
  (estado, evento: { type: 'INC' } | { type: 'DEC' }) => {
    switch (evento.type) {
      case 'INC':
        return { n: estado.n + 1 }
      case 'DEC':
        return { n: estado.n - 1 }
      default:
        return estado
    }
  },
  { n: 0 },
)

La taxonomía como criterio de diseño

Los cuatro creadores no son intercambiables: cada uno codifica una forma distinta de asincronía, y elegir mal se paga en fricción. Un flujo forzado dentro de un fromPromise pierde todos sus valores menos el primero; una petición envuelta en fromCallback te obliga a gestionar a mano una cancelación que fromPromise te regala con su signal. La pregunta guía es siempre la misma: ¿cuántos valores entrega la fuente y en qué dirección viaja la información?

flowchart TD
Q1{cuantos valores emite} -->|uno| P[fromPromise]
Q1 -->|muchos| Q2{necesitas enviarle eventos}
Q2 -->|no| O[fromObservable]
Q2 -->|si| C[fromCallback]
Q1 -->|es una reduccion pura| T[fromTransition]
style P fill:#a6e3a1,color:#11111b
style O fill:#89b4fa,color:#11111b
style C fill:#fab387,color:#11111b
style T fill:#cba6f7,color:#11111b