Muchos actores a la vez: cientos de máquinas hijas

La idea de dar a cada fila su propia máquina es genuinamente buena: encapsula el ciclo de vida de un elemento, permite que una fila esté guardando mientras otra está editando y otra fallando, y elimina de un plumazo los mapas de identificadores a banderas que suelen infestar las listas editables. La idea se vuelve peligrosa cuando el número de filas deja de ser una docena y pasa a ser lo que devuelva el servidor. Mil filas son mil instancias con su snapshot, su buzón, su conjunto de observadores y su cierre reteniendo datos, más mil suscripciones desde la interfaz, más mil entradas en la estructura del padre que las guarda. Ninguna de esas cosas es cara por separado y todas juntas sí lo son. Antes de decidir si el patrón escala hay que saber contar lo que ocupa, y contar exige saber primero qué se comparte y qué se duplica.

Qué se comparte y qué se duplica

La confusión más común consiste en creer que cada actor lleva consigo una copia de la máquina. No es así: la definición —los nodos, las transiciones indexadas, las implementaciones de acciones y guardas— se construye una vez y todas las instancias apuntan a ella. Lo que se duplica es mucho más modesto y también más silencioso.

flowchart TD
A[definicion de la maquina] -->|compartida por todos| B[actor fila 1]
A --> C[actor fila 2]
A --> D[actor fila n]
B --> B1[snapshot con valor y contexto]
B --> B2[buzon de eventos pendientes]
B --> B3[conjunto de observadores]
B --> B4[referencias a hijos y temporizadores]

Cada instancia mantiene cuatro cosas propias. La primera es el snapshot vigente, con el valor finito y el objeto de contexto: pequeño si el contexto guarda escalares, arbitrariamente grande si guarda la fila entera, la respuesta original del servidor y una copia previa para poder deshacer. La segunda es el buzón, normalmente vacío pero con la estructura reservada. La tercera es el conjunto de observadores, que crece con cada componente suscrito a esa fila. La cuarta, y la más traicionera, son las referencias vivas: temporizadores pendientes, actores invocados y, sobre todo, los cierres creados por las implementaciones que capturan variables externas.

El presupuesto por fila

Con esa descomposición se puede hacer una estimación honesta, entendida siempre como orden de magnitud sujeto a medición. La utilidad de la tabla no está en las cifras exactas sino en la proporción entre las filas: muestra dónde mirar cuando el montículo crece.

Proyectada a mil filas con contexto ligero, la factura estructural queda en el orden de un megabyte largo: perfectamente asumible en una aplicación de escritorio y discutible en un dispositivo modesto. Proyectada a mil filas cuyo contexto retiene la respuesta completa del servidor más dos copias, la misma tabla arroja decenas de megabytes y una presión de recolección que se nota en forma de pausas. La conclusión operativa es que el patrón de un actor por fila no falla por el número de actores, falla por lo que cada actor decidió recordar.

Tres arquitecturas para una lista larga

Elegir entre ellas es la decisión estructural de esta lección, y las tres son defendibles según el caso.

La tercera opción es la que mejor envejece en listas grandes y merece que se vea su forma, porque la clave está en crear y detener con simetría estricta.

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

export const lista = setup({
  types: {
    context: {} as { filas: Fila[]; editores: Record<string, ActorRefEditor> },
    events: {} as { type: 'EDITAR'; id: string } | { type: 'CERRAR'; id: string },
  },
  actors: { editor: editorDeFila },
}).createMachine({
  context: { filas: [], editores: {} },
  on: {
    EDITAR: {
      actions: assign(({ context, event, spawn }) => {
        if (context.editores[event.id]) return {}
        const fila = context.filas.find((f) => f.id === event.id)
        const ref = spawn('editor', { id: `editor-${event.id}`, input: { fila } })
        return { editores: { ...context.editores, [event.id]: ref } }
      }),
    },
    CERRAR: {
      actions: [
        stopChild(({ event }) => `editor-${event.id}`),
        assign(({ context, event }) => {
          const resto = { ...context.editores }
          delete resto[event.id]
          return { editores: resto }
        }),
      ],
    },
  },
})

Dos detalles de ese código son la diferencia entre un patrón sano y una fuga garantizada. El primero es la guarda de idempotencia al crear: sin ella, dos eventos de edición sobre la misma fila producen dos actores y el segundo sobrescribe la referencia del primero, que queda vivo y huérfano para siempre. El segundo es que detener el hijo y borrarlo del contexto son dos acciones distintas y ambas son obligatorias: detener sin borrar deja una referencia muerta que sigue reteniendo memoria, y borrar sin detener deja un actor corriendo al que ya nadie puede alcanzar.

Medir en vez de estimar

Toda la aritmética anterior es una hipótesis hasta que se contrasta, y contrastarla es más fácil de lo que parece porque el sistema de actores es observable por construcción. Un contador basado en el flujo de inspección da la cifra más importante de todas: cuántos actores hay vivos ahora mismo y si esa cifra vuelve a bajar cuando debería.

import { createActor } from 'xstate'

let vivos = 0
const actor = createActor(maquina, {
  inspect: (ev) => {
    if (ev.type === '@xstate.actor') vivos++
    if (ev.type === '@xstate.snapshot' && ev.snapshot.status === 'done') vivos--
  },
})
setInterval(() => console.log('actores vivos', vivos), 2000)

Ese número, observado durante un guion que abre y cierra editores repetidamente, responde a la única pregunta que importa sobre fugas: si tras cerrar todos los editores la cuenta no regresa a su valor inicial, hay actores huérfanos y ninguna medición de memoria hará falta para saber que el problema está en la simetría entre creación y parada. La instantánea del montículo entra después, para el segundo diagnóstico: se toma una antes del guion, otra después, se comparan y se examinan los retenedores de los objetos que sobreviven. Ahí es donde aparecen los cierres capturando datos grandes y las suscripciones sin cancelar, que son las dos causas dominantes de crecimiento sostenido en este patrón.