Canales de difusión: avisar a todos sin compartir un hilo

Entre no tener nada y tener un hilo compartido hay una pieza intermedia, disponible en todas partes y de una simplicidad casi insultante: un bus de mensajes por nombre, dentro del origen, al que cualquier documento puede asomarse. Con tres líneas, una pestaña avisa a las demás de que algo cambió. Esa facilidad es precisamente el peligro, porque invita a construir sobre ella cosas que no puede sostener. La disciplina de esta lección consiste en separar con nitidez dos usos que se parecen mucho y son radicalmente distintos: notificar, que es exactamente para lo que sirve, y coordinar, que es exactamente para lo que no sirve, por razones que no dependen de cuánto cuidado pongas al escribirlo.

El canal, y lo que promete exactamente

Se construye con un nombre. Todos los objetos creados con ese mismo nombre dentro del mismo origen quedan conectados entre sí, incluidos los de otras pestañas, los de los iframes, los de los workers y los del Service Worker. Un mensaje enviado se entrega mediante clonado estructurado a todos ellos excepto al que lo envió, detalle que evita el eco pero que despista la primera vez, porque la pestaña que escribe no recibe su propio aviso y tiene que actualizarse por su cuenta.

const canal = new BroadcastChannel('datos');

// Emisor: avisa de QUE cambio, no manda el dato
async function guardarNota(nota) {
  const version = await escribirEnIndexedDB(nota);
  canal.postMessage({ tipo: 'cambio', entidad: 'nota', id: nota.id, version });
}

// Receptores: releen de la fuente de verdad
canal.onmessage = (e) => {
  const { entidad, id, version } = e.data;
  if (version <= versionVista.get(id)) return;   // llegan desordenados
  versionVista.set(id, version);
  recargarDesdeIndexedDB(entidad, id);
};

Conviene situarlo frente a su antecesor, porque mucho código heredado sigue usándolo. Antes de esta API, la forma de avisar entre pestañas era el evento que emite localStorage al escribir, y funcionaba por accidente más que por diseño: obligaba a serializar todo a texto, contaminaba el almacenamiento con datos que no querías guardar, arrastraba el coste de una API síncrona que bloquea el hilo principal y solo servía para notificar entre documentos, nunca hacia un worker. El canal de difusión hace lo mismo de manera explícita, con clonado estructurado en lugar de texto, sin tocar el disco y alcanzando también a los contextos sin ventana. Si encuentras lo primero en tu base de código, migrarlo es una mejora sin contrapartidas.

Lo que el canal promete termina ahí, y conviene enumerar lo que no promete, porque la lista es larga y no está escrita en ningún sitio evidente. No hay orden total entre mensajes de emisores distintos: dos pestañas que emiten a la vez pueden llegar en cualquier orden y en órdenes distintos a cada receptor. No hay confirmación de entrega ni forma de saber si alguien escuchaba. No hay persistencia: una pestaña que abre un segundo después de un mensaje nunca sabrá que existió. No hay membresía: no puedes preguntar cuántos participantes hay. Y no hay transferencia: a diferencia de otros canales, no admite ceder un puerto ni un búfer, solo copias.

Lo que resuelve bien: invalidar, no transportar

Con esa regla en la mano, la lista de problemas que el canal resuelve limpiamente es respetable, y cubre buena parte de lo que una aplicación multipestaña necesita a diario.

El criterio que separa los usos buenos de los malos se puede formular en una sola pregunta: ¿qué pasa si este mensaje se pierde? Si la respuesta es que la interfaz queda un momento desactualizada y se corregirá sola, el canal es la herramienta adecuada. Si la respuesta es que dos pestañas escribirán a la vez, que se duplicará un registro o que un fichero se corromperá, entonces estás usando un timbre como si fuera un cerrojo y el fallo no es cuestión de si ocurrirá, sino de cuándo.

Dos disciplinas hacen que los usos buenos sean robustos. La primera es la monotonía: todo aviso lleva una versión creciente, y el receptor descarta lo que no la supera, con lo que el desorden y la duplicación dejan de importar. La segunda es la idempotencia: procesar dos veces el mismo aviso debe dar el mismo resultado que procesarlo una, lo que se consigue reaccionando siempre con una relectura desde el almacenamiento en vez de aplicando un delta sobre el estado en memoria.

flowchart TB
A[Pestana A escribe en IndexedDB] --> B[Emite aviso con id y version]
B --> C[Pestana B recibe]
B --> D[Pestana C recibe]
B --> E[Pestana D congelada no recibe]
C --> F[Relee de IndexedDB]
D --> F
E --> G[Queda obsoleta hasta que despierte]
style B fill:#89b4fa,color:#11111b
style F fill:#a6e3a1,color:#11111b
style G fill:#f38ba8,color:#11111b

Por qué no es un mecanismo de exclusión mutua

Antes o después alguien propone construir la elección de líder sobre el canal, y el código que resulta siempre se parece a este. Merece la pena escribirlo entero, porque es más instructivo entender por qué falla que evitarlo por decreto.

// ANTIPATRON: esto no elige a nadie, solo lo parece
const miId = crypto.randomUUID();
let soyLider = true;

canal.onmessage = (e) => {
  if (e.data.tipo !== 'candidatura') return;
  if (e.data.id < miId) soyLider = false;      // gana el identificador menor
};

canal.postMessage({ tipo: 'candidatura', id: miId });
setTimeout(() => { if (soyLider) abrirLaBase(); }, 200);

El fallo no está en un detalle corregible, está en cuatro sitios a la vez. El plazo de doscientos milisegundos es una conjetura sobre el tiempo de red de un sistema que no tiene ninguna cota superior conocida; una pestaña ocupada en una tarea larga responderá tarde y ambas se creerán líderes. Una pestaña que abre en el milisegundo doscientos uno nunca vio la ronda y se declarará líder sobre otro que ya lo era. Una pestaña congelada en la caché de retroceso no responde, se la da por ausente, y despierta convencida de su cargo. Y, sobre todo, no hay ninguna operación atómica: entre difundir la candidatura y decidir el resultado hay una ventana en la que otro puede hacer exactamente lo mismo, y ningún participante tiene autoridad para resolver el empate.

Puesto del revés, el diagnóstico se vuelve constructivo. Un mecanismo de exclusión mutua necesita dos ingredientes que este canal no tiene y que ninguna cantidad de código encima puede fabricar. El primero es una operación atómica de adquisición, algo equivalente a comparar e intercambiar, ejecutada por una autoridad que serialice las peticiones simultáneas y responda con un sí a una y un no a las demás; difundir una intención y esperar objeciones no es atómico ni de lejos. El segundo es un detector de fallos fiable, capaz de afirmar que el titular ya no está sin depender de que él coopere anunciándolo. La plataforma tiene las dos cosas, pero no aquí: las tiene en la API de bloqueos, porque el navegador serializa las peticiones y porque destruye él mismo los documentos y sabe cuándo lo ha hecho. Insistir en construirlas sobre un bus de mensajes es reescribir peor algo que ya está ahí.

Hay además dos limitaciones prácticas que el canal impone y que conviene conocer antes de apoyarse en él para nada delicado. La primera es la congelación: un documento en la caché de retroceso y avance no procesa mensajes, y en varios navegadores mantener un canal abierto con escuchadores puede impedir que la página entre en esa caché, con lo que eliges entre recibir avisos o navegar rápido hacia atrás. La segunda es el coste por receptor: cada mensaje se clona íntegro para cada destinatario, de modo que un bus por el que circula tráfico dirigido a un solo interlocutor obliga a todas las pestañas a deserializar mensajes que no les incumben, y eso se paga en el hilo principal de cada una.

Disciplinas para convivir con la difusión

Nada de lo anterior descalifica al canal; lo sitúa. Cuatro hábitos bastan para que resulte una pieza sólida dentro de una arquitectura que apoye sus garantías en otro sitio.

• Sobres con metadatos. Todo mensaje lleva emisor, tipo, versión del protocolo y época del líder. Ignorar los tipos desconocidos y descartar las épocas viejas es lo que permite que convivan pestañas con despliegues distintos.
• Un canal por conversación. Separar el bus de avisos generales de los canales dirigidos a un interlocutor concreto evita que todas las pestañas paguen la deserialización de un tráfico ajeno.
• Reconciliación al despertar. Al recuperar visibilidad o al volver de la caché de retroceso, releer el estado en lugar de confiar en lo que llegó. Los mensajes perdidos no se recuperan; el almacenamiento sí se relee.
• Cerrar el canal. Los canales abiertos mantienen vivas referencias y penalizan la caché de retroceso; cerrarlos al ocultarse la página y reabrirlos al volver es barato y limpio.

// Ciclo de vida honesto del canal, atado a la visibilidad del documento
let canal = null;

function abrir() {
  canal = new BroadcastChannel('datos');
  canal.onmessage = manejar;
  reconciliarDesdeIndexedDB();      // lo perdido no se recupera: se relee
}

addEventListener('pagehide', () => { canal?.close(); canal = null; });
addEventListener('pageshow', abrir);