Batching: agrupar la propagación

El orden topológico resuelve un problema espacial: dado UN cambio, en qué orden recorrer el grafo para no ver inconsistencias. Pero las aplicaciones reales no cambian un dato a la vez: un manejador de evento escribe tres señales seguidas, una respuesta de red actualiza cinco campos. Si cada escritura dispara su propia propagación, el grafo se recorre tantas veces como escrituras, y entre una y otra queda expuesto en estados que son consistentes pero no deseados: reflejan una actualización a medio aplicar. El batching es la respuesta a este problema temporal: agrupar las escrituras y propagar una sola vez, al final. Es la consistencia en el tiempo, hermana del orden topológico que da la consistencia en el espacio.

El problema: muchas escrituras, muchas propagaciones

Imagina un nombre compuesto de dos señales y un derivado que las une.

const nombre = signal("Ada")
const apellido = signal("King")
const completo = computed(() => `${nombre()} ${apellido()}`)

// actualizamos a Ada Lovelace en dos pasos
setNombre("Ada")         // completo se recalcula a "Ada King": intermedio no deseado
setApellido("Lovelace")  // completo se recalcula a "Ada Lovelace": final

Aquí no hay glitch: “Ada King” fue un estado perfectamente consistente del grafo —existió mientras solo el apellido estaba pendiente—. El problema es otro: es un estado que nunca quisimos exponer. Si un efecto guarda el nombre en disco o lo envía a un servidor, guardará “Ada King”, un valor que jamás fue la intención del programa. Y el grafo se recorrió dos veces cuando una habría bastado.

batch: coalescer y ocultar

El batch difiere la propagación hasta que un bloque de escrituras termina, y entonces propaga una sola vez. Las escrituras dentro del lote solo marcan sus nodos; nada se recalcula ni ningún efecto corre hasta cerrar el bloque.

batch(() => {
  setNombre("Ada")
  setApellido("Lovelace")
})
// una sola propagacion al cerrar el lote:
// completo se recalcula UNA vez y vale "Ada Lovelace"
// ningun efecto vio jamas "Ada King"

Por dentro, un batch no es más que un contador de profundidad y un conjunto de nodos pendientes. Mientras haya un lote abierto, escribir solo apila; al cerrar el último, se drena todo de una vez, en orden topológico, y recién entonces corren los efectos.

let profundidad = 0
const pendientes = new Set()

function batch(fn) {
  profundidad++
  try {
    fn()                       // las escrituras de fn solo apilan en pendientes
  } finally {
    profundidad--
    if (profundidad === 0) drenar()   // solo el batch mas externo propaga
  }
}
function marcarSucio(nodo) {
  pendientes.add(nodo)
  if (profundidad === 0) drenar()      // sin batch abierto: propaga al instante
}
function drenar() {
  const cono = ordenarPorAltura(pendientes)  // orden topologico
  pendientes.clear()
  for (const n of cono) n.recalcular()
  correrEfectos()                      // los efectos, una vez, al final
}

El contador profundidad resuelve el anidamiento con elegancia: si un batch llama a una función que a su vez abre otro batch, solo el más externo dispara el drenar. Los lotes anidados se funden en una única propagación, así que componer funciones que cada una agrupa sus escrituras no multiplica las pasadas —igual que una transacción anidada en una base de datos: solo el commit exterior es visible—. El batching rinde entonces en las dos direcciones que nos importan: en trabajo, varias escrituras que comparten dependientes recorren el grafo una vez; en consistencia, el estado prematuro “Ada King” nunca se materializa para un observador. Un lote es, en la práctica, una transición atómica de un estado consistente y deseado a otro.

Batching automático por microtarea

Escribir batch a mano en cada sitio sería tedioso y fácil de olvidar. Los sistemas modernos añaden batching implícito programando el vaciado —el flush— como una microtarea al final del tick síncrono actual. Cada escritura marca su nodo como sucio y, si aún no hay un flush programado, encola uno; todas las escrituras síncronas del mismo tick se funden en esa única pasada.

contador.set(1)
contador.set(2)
contador.set(3)
// sin batch explicito: tres marcas de sucio, un solo flush en la microtarea
// los efectos corren una vez y observan 3

sequenceDiagram
participant U as codigo de usuario
participant G as grafo
participant E as efectos
U->>G: setNombre Ada marca sucio
U->>G: setApellido Lovelace marca sucio
U->>E: fin del tick programa un solo flush
E->>G: recalcula completo una vez con valores finales
E->>E: los efectos corren una vez con Ada Lovelace

Cada ecosistema tiene su variante de esta idea, y en 2026 la convergencia es casi total. React agrupa de forma automática todas las actualizaciones de un tick desde la versión 18, incluso dentro de promesas y temporizadores, y ofrece startTransition para diferir actualizaciones de baja prioridad. Solid y Preact Signals exponen un batch explícito además de coalescer efectos. Vue programa su cola de efectos y la vacía en el nextTick. Angular corre los efectos de señales en una fase planificada, glitch-free y agrupada. Svelte 5 vacía sus runes en una microtarea. La propuesta de Signals de TC39 deja el flush en manos de un Watcher que el consumidor programa: el batching es una política sobre cuándo drenar los efectos pendientes.

Sabores de flush

Todos los sistemas agrupan, pero no todos vacían el lote en el mismo momento, y esa elección de cuándo drenar tiene consecuencias visibles.

La regla de diseño es que los efectos que producen salida observable —pintar, guardar, pedir— deben correr una sola vez por lote y con valores finales, sea cual sea el sabor de flush. El cuándo se elige por latencia y por el tipo de efecto; el cuántas veces siempre debe ser uno. Cuando batching y orden topológico colaboran, esa promesa se cumple por construcción, y el resto son detalles de sintonía fina sobre en qué instante exacto libera el sistema su trabajo acumulado.