La cola de efectos

La cola de efectos parece un detalle de implementación del lote y es bastante más: es la estructura que separa la fase de marcado de la de ejecución, y por tanto es parte de la garantía glitch-free del nivel 5. Su diseño —qué estructura usar, cómo vaciarla, qué hacer con lo que se añade durante el vaciado— tiene consecuencias observables en el comportamiento del motor.

La cola es parte de la corrección

Vuelve al nivel 5. La garantía glitch-free se apoyaba en un invariante: ningún cuerpo se ejecuta durante la fase de marcado. Si un efecto se ejecutara mientras se marca, leería nodos aún sin marcar y vería una mezcla de estados.

La cola es lo que hace cumplir ese invariante. Cuando el marcado encuentra un efecto, no lo ejecuta: lo encola. La ejecución ocurre después, cuando el marcado ha terminado.

function marcar(fuente, estado) {
  for (const obs of fuente.observadores) {
    if (obs.estado >= estado) continue;
    const antes = obs.estado;
    obs.estado = estado;
    if (obs.efecto) planificar(obs);        // ENCOLA, no ejecuta
    if (antes === LIMPIO) marcar(obs, QUIZA);
  }
}

Cambiar ese planificar por una ejecución directa reintroduce los glitches inmediatamente. Por eso la cola no es una optimización de agrupamiento que se pueda desactivar: es estructural.

Qué estructura usar

Tres opciones, con propiedades distintas.

Un array. Orden de encolado, deduplicación manual con una bandera por nodo. Es lo que usan varios motores porque es el más rápido de recorrer y permite índices.

Un conjunto. Deduplicación automática, orden de inserción, y la propiedad valiosísima de que iterar con for...of recorre también lo añadido durante la iteración. Es lo que usaremos.

Una cola de prioridad. Permite ordenar por un criterio: profundidad en el árbol de componentes, prioridad declarada, o cualquier otro. Es lo que hacen los motores que quieren garantizar que un efecto de padre corre antes que uno de hijo.

// Con conjunto: el vaciado recoge tambien lo anadido durante el vaciado
function vaciar(cola) {
  for (const efecto of cola) {
    cola.delete(efecto);                       // permite reencolarse mas tarde
    if (efecto.estado !== LIMPIO) actualizar(efecto);
  }
}

El delete antes de ejecutar es deliberado. Si el efecto vuelve a ensuciarse durante el mismo vaciado —porque otro efecto escribió algo que él lee—, se reencola al final y se vuelve a recorrer. Sin el delete, seguiría en el conjunto y no se podría distinguir de una entrada ya procesada.

Qué orden garantizar

El orden dentro de la cola es observable por el programador, y aquí hay una decisión real que tomar.

Orden de encolado. El más simple. Depende del orden en que el marcado recorrió las listas de observadores, que a su vez depende del orden en que se tejieron las aristas. Es determinista para una ejecución dada pero difícil de predecir leyendo el código.

Orden de creación. Los efectos se ejecutan en el orden en que se crearon. Como los efectos suelen crearse recorriendo el árbol de componentes de arriba abajo, esto produce el orden natural de padres antes que hijos.

Orden por profundidad en el árbol de dueños. Explícito y estable, con el mismo resultado que el anterior pero sin depender de cuándo se creó cada cosa.

Los motores reales tienden a las dos últimas, porque el orden entre efectos hermanos tiene consecuencias visibles: si un efecto mide el DOM y otro lo modifica, el orden decide si la medición es correcta.

Reentrada y protección

Efectos añadidos durante el vaciado

Este es el caso interesante. Un efecto que se ejecuta puede escribir una señal, y esa escritura puede ensuciar otros efectos, que se añaden a la cola que se está vaciando.

El comportamiento correcto es procesarlos en el mismo vaciado. Si no, quedarían pendientes hasta la siguiente escritura, y el sistema terminaría el ciclo con nodos sucios sin resolver, es decir, con la invariante rota.

const a = senal(0), b = senal(0);
efecto(() => { if (a() < 3) b.set(a()); });    // efecto que escribe
efecto(() => registrar('b vale ' + b()));

a.set(1);
// vaciado: corre el primero, escribe b, encola el segundo, corre el segundo

El conjunto lo hace de forma natural. Con un array habría que usar un índice en lugar de un for...of para recoger lo añadido, y con una cola de prioridad hay que insertar respetando el orden.

flowchart TB
M[marcado] --> E[efectos encolados]
E --> V[vaciado]
V --> X[ejecutar efecto]
X --> W{el efecto escribe}
W -->|si| N[se encolan mas efectos]
N --> V
W -->|no| S{queda algo en la cola}
S -->|si| V
S -->|no| F[ciclo terminado]
style M fill:#89b4fa,color:#11111b
style E fill:#f9e2af,color:#11111b
style V fill:#cba6f7,color:#11111b
style X fill:#cba6f7,color:#11111b
style W fill:#f9e2af,color:#11111b
style N fill:#fab387,color:#11111b
style S fill:#f9e2af,color:#11111b
style F fill:#a6e3a1,color:#11111b

La protección contra cascadas infinitas

Un efecto que escribe una señal de la que depende produce un bucle infinito: se ejecuta, escribe, se ensucia, se reencola, se ejecuta. El vaciado no termina nunca y el hilo se cuelga.

La defensa estándar es un contador de iteraciones con un umbral.

function vaciar(cola) {
  let vueltas = 0;
  for (const efecto of cola) {
    if (++vueltas > 10000) {
      cola.clear();
      throw new Error('bucle infinito de actualizaciones: un efecto escribe lo que lee');
    }
    cola.delete(efecto);
    if (efecto.estado !== LIMPIO) actualizar(efecto);
  }
}

El umbral es arbitrario y tiene que ser generoso, porque una cascada legítima puede ser larga. Lo importante no es el número sino que el mensaje diga qué buscar: un efecto que escribe una fuente de la que depende, directa o transitivamente.

Todos los motores tienen esta protección con umbrales parecidos y mensajes de error que apuntan a la misma causa. Es una de esas piezas que solo se aprecian cuando te salvan de un cuelgue en producción.