spawn y spawnChild: crear actores y su ciclo de vida

Un actor que no puede crear otros actores es una isla estéril. La segunda capacidad del modelo de Hewitt —engendrar hijos— es la que convierte un actor solitario en un sistema. XState v5 te da dos maneras de hacerlo, y elegir bien entre ellas define la claridad de tu diseño: spawn cuando necesitas conservar la dirección del hijo para hablarle después, y spawnChild cuando lo lanzas y lo gestionas por su nombre. Detrás de ambas hay un ciclo de vida que debes controlar, porque un actor que nadie detiene es una fuga de memoria que respira.

spawn: un hijo con referencia en el context

spawn vive dentro de la acción assign, y por una buena razón: crear el hijo y guardar su dirección son un solo acto. La función que le pasas a assign recibe un objeto con la utilidad spawn; al invocarla, XState instancia y arranca el actor hijo, y te devuelve su referencia —un ActorRef— para que la almacenes en el context. Desde ese momento tienes una dirección a la que enviar mensajes.

import { setup, assign, fromPromise } from "xstate"

const maquina = setup({
  actors: {
    cargador: fromPromise(async () => (await fetch("/datos")).json()),
  },
}).createMachine({
  context: { ref: null },
  on: {
    INICIAR: {
      actions: assign({
        // spawn crea el hijo, lo arranca y devuelve su ActorRef.
        ref: ({ spawn }) => spawn("cargador", { id: "carga1" }),
      }),
    },
  },
})

Guardar la referencia en el context es lo que te permitirá, en la próxima lección, enviarle eventos con sendTo. La regla mental es directa: si vas a necesitar hablarle al hijo más tarde, usa spawn y quédate con su dirección. Fíjate en setup: registrar la lógica del hijo por nombre en el bloque actors es la forma idiomática de la v5, porque desacopla el plano de su uso y da tipos precisos a spawn.

spawnChild: un hijo por id

A veces creas un actor que hace su trabajo por su cuenta y no necesitas conservar su referencia en el estado —un temporizador, un registrador de eventos, un sincronizador de fondo—. Para eso está spawnChild: una acción de crear y olvidar. El hijo existe y corre, pero se identifica por un id en lugar de por una referencia guardada en el context.

import { setup, spawnChild, stopChild, fromCallback } from "xstate"

const maquina = setup({
  actors: {
    reloj: fromCallback(({ sendBack }) => {
      const t = setInterval(() => sendBack({ type: "TIC" }), 1000)
      return () => clearInterval(t)
    }),
  },
}).createMachine({
  // Crear y olvidar: sin referencia en el context, solo un id.
  entry: spawnChild("reloj", { id: "reloj1" }),
  on: {
    PARAR: { actions: stopChild("reloj1") },   // lo detienes por su id
  },
})

La elección entre las dos herramientas no es de estilo, sino de intención. spawn dice “voy a mantener una conversación con este actor”. spawnChild dice “este actor tiene una tarea y se gestiona por su nombre”. Poner en el context una referencia que nunca vas a usar es ruido; lanzar con spawnChild algo a lo que necesitarás responder con precisión es perder su dirección antes de necesitarla.

Un supervisor real combina las dos herramientas: engendra a sus trabajadores al entrar, guarda las referencias que necesitará y los detiene explícitamente al terminar. Este patrón —crear al entrar, detener al salir— es el esqueleto de casi todo actor padre.

import { setup, assign, stopChild } from "xstate"

const supervisor = setup({
  actors: { trabajador },
}).createMachine({
  context: { refs: [] as ActorRef[] },
  initial: "activo",
  states: {
    activo: {
      entry: assign({
        refs: ({ spawn }) => [
          spawn("trabajador", { id: "t1" }),
          spawn("trabajador", { id: "t2" }),
        ],
      }),
      on: { TERMINAR: "cerrado" },
    },
    cerrado: {
      entry: [stopChild("t1"), stopChild("t2")],   // limpieza explicita
      type: "final",
    },
  },
})

El ciclo de vida y su final

Todo actor recorre el mismo arco. Nace creado, pasa a activo cuando arranca —al instanciarlo con createActor y llamar a start, o en el instante en que un padre lo engendra con spawn—, procesa eventos mientras vive, y termina detenido. Un actor se detiene por tres vías: porque su lógica llega a un estado final y concluye por sí mismo, porque falla con un error, o porque alguien lo detiene explícitamente con stopChild. Al detenerse, ejecuta su limpieza —esa función que devolvías en fromCallback— y libera lo que retenía.

flowchart LR
A[creado] -- start o spawn --> B[activo]
B -- procesa eventos --> B
B -- final, error o stopChild --> C[detenido]
style A fill:#f9e2af,color:#11111b
style B fill:#a6e3a1,color:#11111b
style C fill:#eba0ac,color:#11111b

Conviene contrastar spawn y spawnChild con la tercera vía de crear actores, invoke, que verás a fondo en el nivel 14. invoke ata la vida del actor a un estado concreto de la máquina: el actor nace al entrar en ese estado y se detiene automáticamente al salir. Es declarativo y perfecto cuando la existencia del hijo coincide con la permanencia en un estado —cargar datos mientras estás en cargando—. spawn y spawnChild, en cambio, son imperativos: creas el hijo cuando lo decides con una acción, y vive hasta que tú u otro lo detengáis, o hasta que su padre muera y se lo lleve consigo.