Batching: una propagación en lugar de cinco

Un manejador de evento rara vez escribe un solo dato. Abre un modal, marca un elemento como seleccionado, actualiza un contador y limpia un mensaje de error, y lo hace en cuatro líneas consecutivas. Si cada línea dispara su propia propagación, el sistema recorre cuatro veces un grafo que en gran parte es el mismo, ejecuta cuatro veces efectos que producen la misma salida final y toca el DOM cuatro veces para que el usuario vea un único cambio. El batching es la respuesta a este desperdicio: retener las escrituras, acumular los nodos sucios y propagar una sola vez cuando el bloque termina. No es una optimización marginal, es la diferencia entre pagar por escritura y pagar por transición.

La factura de propagar cinco veces

Sean cinco escrituras consecutivas sobre señales distintas cuyos conos de dependientes se solapan. Sin agrupar, el coste total es la suma de los cinco conos, y cada nodo compartido se recalcula tantas veces como escrituras lo alcanzan. Agrupando, el coste es el tamaño de la unión de los conos, y cada nodo se recalcula exactamente una vez.

// sin batching: cinco propagaciones independientes
setAbierto(true)      // recorre su cono
setSeleccion(id)      // recorre su cono, que solapa con el anterior
setContador(n + 1)    // recorre su cono
setError(null)        // recorre su cono
setFiltro("todos")    // recorre su cono
// coste: suma de los cinco conos, nodos compartidos recalculados cinco veces

// con batching: una sola propagacion
batch(() => {
  setAbierto(true); setSeleccion(id); setContador(n + 1)
  setError(null);   setFiltro("todos")
})
// coste: union de los cinco conos, cada nodo recalculado una vez

El ahorro depende por completo del solapamiento. Si los cinco conos son disjuntos, agrupar ahorra las cuatro tandas de efectos y los cuatro parches redundantes al DOM, pero el trabajo de recálculo es el mismo. Si los cinco conos convergen en un nodo raíz caro, por ejemplo una lista derivada que ordena y filtra miles de elementos, agrupar reduce cinco ejecuciones de esa función a una sola. Por eso el batching rinde más cuanto más profundo y compartido es el grafo, que es exactamente la situación de cualquier aplicación no trivial.

Vale la pena expresar la relación con números. Si las cinco escrituras alcanzan un derivado común cuyo recálculo cuesta un milisegundo, sin agrupar se pagan cinco milisegundos y con lote uno, y el ahorro no depende de lo rápido que sea el motor sino de la aritmética del solapamiento. Si además ese derivado alimenta a diez efectos, sin agrupar se ejecutan cincuenta y con lote diez. El batching es, en este sentido, una de las poquísimas optimizaciones cuyo beneficio se puede predecir sobre el papel antes de medir, porque no depende de constantes ocultas del entorno sino de la forma del grafo.

Cómo se agrupa por dentro

Un agrupador correcto necesita solo dos cosas: un contador de profundidad para soportar anidamiento y un conjunto de nodos pendientes. Mientras el contador sea mayor que cero, escribir solo apila; al volver a cero, se drena todo en orden de dependencias y recién entonces corren los efectos.

let profundidad = 0
const pendientes = new Set<Nodo>()

function batch<T>(fn: () => T): T {
  profundidad++
  try { return fn() }
  finally { if (--profundidad === 0) drenar() }
}

function marcarSucio(n: Nodo): void {
  pendientes.add(n)                    // el Set deduplica escrituras repetidas
  if (profundidad === 0) drenar()      // sin lote abierto se propaga al instante
}

function drenar(): void {
  const cono = ordenarPorAltura(pendientes)  // orden topologico
  pendientes.clear()
  for (const n of cono) n.recalcular()
  correrEfectos()                            // una sola tanda, con valores finales
}

El uso de un conjunto es lo que convierte tres escrituras sobre la misma señal en una sola marca, y el contador de profundidad es lo que hace que componer funciones que ya agrupan por su cuenta no multiplique las pasadas: solo el cierre del lote más externo dispara el vaciado. Es la misma semántica que las transacciones anidadas de una base de datos, donde únicamente el commit exterior es observable.

sequenceDiagram
participant U as codigo
participant P as pendientes
participant G as grafo
participant E as efectos
U->>P: cinco escrituras marcan nodos sucios
U->>G: cierre del lote dispara el drenado
G->>G: ordena por altura y recalcula la union de conos
G->>E: una sola tanda de efectos con valores finales
E->>E: un unico parche al DOM

Hay dos detalles de implementación que separan un agrupador de juguete de uno utilizable. El primero es qué ocurre si un efecto escribe durante el drenado: el conjunto de pendientes se está recorriendo mientras alguien lo modifica, y sin un límite explícito de iteraciones un ciclo entre dos efectos produce un bucle infinito en lugar de un error diagnosticable. El segundo es la seguridad frente a excepciones: si el bloque agrupado lanza, el contador debe decrementarse igualmente, porque un lote que queda abierto convierte todas las escrituras posteriores de la aplicación en marcas que nadie drena, y el síntoma es una interfaz que deja de responder sin ningún error en la consola.

function drenarSeguro(): void {
  let vueltas = 0
  while (pendientes.size > 0) {
    if (++vueltas > 100) throw new Error("ciclo de efectos no convergente")
    const lote = ordenarPorAltura(pendientes)
    pendientes.clear()
    for (const n of lote) n.recalcular()
  }
  correrEfectos()
}

Sabores de vaciado y latencia

Todos los sistemas agrupan, pero difieren en el momento del vaciado, y esa elección cambia el perfil de latencia mucho más que el de trabajo total.

La regla de diseño que atraviesa los cuatro sabores es que un efecto con salida observable debe ejecutarse una sola vez por transición y con valores finales. El cuándo se elige por latencia; el cuántas veces siempre debe ser uno. En 2026 la convergencia es casi total: React agrupa automáticamente todas las actualizaciones de un tick incluidas las que ocurren tras una promesa, Vue vacía su cola en el nextTick, Angular planifica los efectos de señales en una fase agrupada, Svelte vacía sus runes en una microtarea, y la propuesta de Signals de TC39 delega el vaciado en un observador que el consumidor programa a su gusto.

// MAL: una propagacion por elemento, cien recorridos del grafo
for (const id of ids) {
  const item = await cargar(id)
  añadirAlEstado(item)          // cada await rompe el lote implicito
}

// BIEN: se acumula fuera del estado y se escribe una vez
const items = await Promise.all(ids.map(cargar))
batch(() => { for (const it of items) añadirAlEstado(it) })