El sistema de actores: la jerarquía y el system

Un actor aislado es poco más que una curiosidad. La potencia del modelo aparece cuando muchos actores se organizan en una estructura viva: un árbol donde cada padre supervisa a sus hijos, con una raíz que lo sostiene todo y un registro común que permite encontrarse sin conocerse de antemano. XState llama a esa estructura el sistema. Es la culminación de los tres axiomas de Hewitt y la respuesta a la pregunta que abría el nivel: ¿por qué este modelo de 1973 escala a lógica arbitrariamente compleja cuando otros se ahogan? Porque el sistema de actores no es una colección de piezas, sino un árbol de responsabilidades.

El árbol de actores: raíz, padres, hijos

Cuando instancias un actor con createActor y lo arrancas, no creas solo un actor: creas un sistema. Ese primer actor es la raíz, y todo lo que engendre —con spawn, spawnChild o invoke— cuelga de él formando un árbol. Cada actor tiene exactamente un padre (salvo la raíz, que no tiene ninguno) y puede tener cualquier número de hijos. La estructura es idéntica a la de un árbol de supervisión de Erlang, y no por casualidad.

flowchart TD
R[actor raiz la app] --> A[actor auth]
R --> C[actor carrito]
C --> C1[actor item 1]
C --> C2[actor item 2]
R -. descubre por systemId .-> A
style R fill:#cba6f7,color:#11111b
style A fill:#89b4fa,color:#11111b
style C fill:#89b4fa,color:#11111b
style C1 fill:#a6e3a1,color:#11111b
style C2 fill:#a6e3a1,color:#11111b

La jerarquía no es decorativa: gobierna el ciclo de vida. Cuando un actor se detiene, se lleva consigo a todos sus descendientes; detener la raíz apaga el sistema entero de forma ordenada, de las hojas hacia el tronco, ejecutando cada limpieza a su paso. Esta contención del ciclo de vida por subárboles es lo que evita que detener una parte de la app deje procesos huérfanos vivos en otra. El árbol no es un diagrama que dibujas después para documentar; es la estructura que XState usa en tiempo de ejecución para decidir quién vive y quién muere, y cuándo.

El system: registro y descubrimiento

El árbol resuelve la relación entre padres e hijos, pero muchos actores necesitan hablar con otros que no son ni sus padres ni sus hijos: el carrito quiere consultar al actor de autenticación, que vive en otra rama. Pasar referencias a mano por todo el árbol —el temido prop drilling del nivel de contexto— sería insufrible. Para eso existe el system: un registro compartido por todos los actores del árbol, donde un actor puede publicarse con un nombre global y otro puede encontrarlo por ese nombre.

import { createActor } from "xstate"

// La raiz define el sistema. Se le puede dar un systemId.
const app = createActor(maquinaApp, { systemId: "app" })
app.start()

import { assign, sendTo } from "xstate"

// Un hijo se registra con systemId al ser creado: ahora es descubrible.
const registrar = assign({
  auth: ({ spawn }) => spawn("autenticacion", { systemId: "auth" }),
})

// Cualquier actor del sistema lo encuentra por su nombre, sin tener su referencia.
const cerrarSesion = sendTo(
  ({ system }) => system.get("auth"),
  { type: "LOGOUT" },
)

La diferencia entre el id de la lección 3 y el systemId de esta es la diferencia entre lo local y lo global, y merece un cuadro claro porque confundirlos produce actores que no se encuentran o nombres que chocan.

Dos actores distintos pueden tener hijos con el mismo id sin colisionar, porque el id solo tiene sentido dentro de un padre. El systemId, en cambio, es único en todo el sistema y sirve para el descubrimiento a distancia: es la guía telefónica del árbol, y por eso un systemId repetido es un error.

Este acceso al registro también permite que un actor localice a sus vecinos al nacer, en lugar de esperar a que le manden sus direcciones. Un carrito puede pedirle al system la dirección de auth en el inicializador de su propio context:

import { setup, sendTo } from "xstate"

const carrito = setup({}).createMachine({
  // Al nacer, localiza a auth por su systemId y guarda su direccion.
  context: ({ system }) => ({ auth: system.get("auth") }),
  on: {
    PAGAR: { actions: sendTo(({ context }) => context.auth, { type: "VERIFICA" }) },
  },
})

Y la raíz teje el árbol entero: engendra a los grandes subsistemas, registra con systemId a los que deben ser descubribles desde cualquier rama, y a partir de ahí cada subárbol se organiza por su cuenta.

import { setup, createActor, spawnChild } from "xstate"

const app = setup({
  actors: { auth, carrito },
}).createMachine({
  entry: [
    spawnChild("auth", { systemId: "auth" }),        // descubrible por todos
    spawnChild("carrito", { id: "carrito" }),
  ],
})

createActor(app, { systemId: "app" }).start()         // aqui nace el sistema

Por qué el modelo escala

Aquí converge todo el nivel. Tres propiedades, que en las lecciones anteriores aparecían sueltas, se revelan ahora como las tres razones por las que un sistema de actores crece sin colapsar.

La localidad del fallo merece detenerse. En un sistema de estado compartido, un error a mitad de una mutación puede dejar los datos en un estado imposible que envenena todo lo que los lea después. En un árbol de actores, el radio de daño de un fallo está acotado por la estructura: como un actor solo puede afectar a otros enviándoles mensajes, y como el estado corrupto vive encerrado tras su buzón, el desastre no se filtra. El padre, que supervisa, decide si reinicia al hijo caído, lo ignora o escala el problema. Es la traducción a estado de aplicación de la filosofía let it crash de Erlang: no intentes que nada falle jamás; haz que el fallo de una parte no arrastre al todo.

La composición es la segunda palanca de escala, y es la que distingue al modelo de una simple colección de máquinas. Como un actor puede ser hijo de otro y padre de terceros, un subsistema entero —el carrito con sus ítems, cada uno con su propia lógica— se comporta hacia fuera como un único actor con un buzón y una snapshot. Puedes razonar sobre el carrito sin abrir sus ítems, igual que razonas sobre una función sin leer su cuerpo. Esa capacidad de encapsular un subárbol tras una sola dirección es lo que mantiene manejable un sistema de miles de actores.