Sincronizar entre pestañas: propagar el estado con el canal de difusión

En el momento en que un usuario abre una segunda pestaña de tu aplicación, dejas de tener un store y pasas a tener varias réplicas independientes de un mismo modelo, cada una con su propia línea temporal, sin conocimiento la una de la otra y divergiendo desde la primera interacción. La consecuencia es visible para el usuario y siempre le parece un error: cierra la sesión en una pestaña y la otra sigue mostrando su nombre, cambia el idioma y solo cambia donde lo tocó, añade un elemento al carrito y la otra copia sigue vacía. El canal de difusión del navegador resuelve el transporte entre esas réplicas en tres líneas, y esa facilidad es precisamente la trampa: lo que tienes delante no es un problema de mensajería sino un sistema distribuido en miniatura, con sus bucles, sus conflictos de escritura concurrente, sus réplicas dormidas y su pregunta incómoda sobre quién tiene razón. Esta lección se ocupa de esas cuatro cosas, porque el transporte no vuelve a aparecer después del primer apartado.

Réplicas divergentes y qué divergencias importan

No toda divergencia entre pestañas es un problema, y confundirlas lleva a sincronizar demasiado, que es un error tan caro como no sincronizar nada. Hay estado que es legítimamente propio de cada pestaña: el desplazamiento de la página, el panel que el usuario tiene abierto aquí, el foco, la posición del cursor, el elemento seleccionado en esta vista. Propagar eso produce una experiencia poltergeist en la que una pestaña se mueve sola porque el usuario está trabajando en otra, y es un fallo peor que la divergencia que pretendía corregir.

Las divergencias que sí importan son tres. La primera es la identidad: sesión, autenticación, permisos, usuario activo. Su divergencia no es una molestia sino un problema de seguridad, porque una pestaña que sigue creyendo que hay sesión mostrará datos y aceptará operaciones que ya no deberían existir. La segunda son las preferencias globales del usuario —tema, idioma, unidades—, cuya divergencia es puramente irritante pero universalmente percibida como error. La tercera son los datos compartidos del dominio que el usuario reconoce como una sola cosa: el carrito, los borradores, el contador de no leídos.

Hay una cuarta categoría que se confunde con la tercera y conviene separarla: la caché de datos del servidor. Propagar su contenido entre pestañas es replicar una réplica, con todos los inconvenientes de la replicación y ninguna de sus ventajas, porque el original sigue estando a una petición de distancia. Lo que sí tiene sentido propagar es la invalidación, el aviso de que ciertos datos caducaron, dejando que cada pestaña decida si los vuelve a pedir ahora o cuando alguien los mire. Es la diferencia entre enviar el dato y enviar la noticia, y casi siempre gana la noticia.

El canal y el middleware que reenvía

El canal de difusión es una tubería con nombre entre contextos del mismo origen: quien publica no se recibe a sí mismo, y todos los demás reciben una copia estructurada del mensaje. Encaja de forma natural con una arquitectura de acciones porque ya tienes la unidad de propagación resuelta: una acción es un objeto serializable que describe un cambio, exactamente lo que un canal necesita transportar. El middleware es el sitio idiomático para conectarlo, porque ve todas las acciones y puede decidir en el mismo punto qué sale y qué entra.

const canal = new BroadcastChannel('estado-app')
const PROPAGABLES = new Set(['sesion/cerrada', 'ajustes/temaCambiado', 'carrito/anadido'])

export const sincronizarPestanas: Middleware = (store) => {
  canal.onmessage = (e) => {
    // Se marca el origen para que el propio middleware no lo reenvie.
    store.dispatch({ ...e.data, meta: { ...e.data.meta, remota: true } })
  }
  return (next) => (accion) => {
    const resultado = next(accion)
    if (PROPAGABLES.has(accion.type) && !accion.meta?.remota) {
      canal.postMessage({ type: accion.type, payload: accion.payload, meta: { emitida: Date.now() } })
    }
    return resultado
  }
}

Tres decisiones están condensadas ahí y conviene hacerlas explícitas. La primera es la marca de origen: sin ella, la acción que llega del canal se vuelve a publicar y las pestañas se reenvían mensajes indefinidamente. La segunda es la lista blanca: se propaga lo que está enumerado, nunca todo, porque la lista negra deja pasar por omisión cada acción nueva que alguien añada y el fallo aparecerá lejos de quien lo causó. La tercera es que se propaga después de reducir, de modo que la acción se aplica localmente aunque el canal falle.

Concurrencia: eco, orden y quién manda

Propagar acciones funciona bien mientras los cambios sean conmutativos o raros, y deja de funcionar en cuanto dos pestañas modifican lo mismo casi a la vez. No hay reloj común, la marca de tiempo de cada pestaña procede de un dispositivo que puede estar desajustado, y el orden en que llegan los mensajes no es necesariamente el orden en que se emitieron. Es el problema clásico de la replicación multimaestro, reducido a un navegador pero con la misma estructura: sin coordinación, dos réplicas que aceptan escrituras acaban en estados distintos.

// Eleccion de lider: el bloqueo se mantiene mientras la pestana viva.
navigator.locks.request('lider-app', { mode: 'exclusive' }, async () => {
  store.dispatch(sesion.liderazgoAsumido())
  await new Promise(() => {}) // no resolver nunca: soltar el bloqueo al cerrarse
})

Hay tres arquitecturas posibles y elegir bien es casi todo el trabajo. La primera propaga acciones entre iguales, es la más simple y es correcta cuando los cambios son idempotentes o de campo único; la última escritura gana y nadie sufre. La segunda elige una pestaña líder mediante un bloqueo con nombre —la única primitiva del navegador que da exclusión mutua real entre contextos— y hace que solo el líder hable con el servidor y difunda los resultados, con las demás actuando como vistas; es la arquitectura correcta cuando hay conexiones persistentes, sondeo o trabajo caro que no debe multiplicarse por el número de pestañas. La tercera renuncia a la sincronización directa y designa al almacenamiento persistente como fuente de verdad, propagando solo la señal de que algo cambió para que cada pestaña vuelva a leer.

flowchart TD
P1[pestana uno] -->|accion propagable| C[canal de difusion]
P2[pestana dos] -->|accion propagable| C
C -->|marcada como remota| P1
C -->|marcada como remota| P2
L[bloqueo con nombre] --> LD[pestana lider]
LD -->|unica que habla con el servidor| S[servidor]
LD -->|difunde resultados| C
style C fill:#89b4fa,color:#11111b
style LD fill:#a6e3a1,color:#11111b

Queda el caso que rompe cualquiera de las tres si no se atiende: la pestaña dormida. Una pestaña en segundo plano recibe menos tiempo de ejecución, puede ser descartada por el navegador y, cuando el usuario vuelve a ella tras una hora, ha perdido todos los mensajes emitidos mientras no existía. La propagación incremental de acciones no es suficiente por sí sola, porque asume que nadie se pierde nada. La solución es tratar el retorno a primer plano como una reconciliación explícita: al recuperar visibilidad, la pestaña no reproduce lo que se perdió sino que vuelve a leer el estado autoritativo y descarta su versión de lo compartido.

Señales en lugar de datos, y las alternativas al canal

Hay una simplificación que casi siempre mejora el diseño y que conviene considerar antes de escribir ningún reducer nuevo: propagar la noticia de que algo cambió en lugar de propagar el cambio. Una pestaña que recibe la señal de que el carrito se modificó simplemente invalida su caché y vuelve a pedirlo; una que recibe la señal de cierre de sesión descarta su estado y navega. Con eso desaparecen de golpe la serialización de cargas útiles, la compatibilidad entre versiones desplegadas, el orden de llegada y buena parte de los conflictos, porque nadie está replicando estado sino avisando de que el suyo caducó. El coste es una petición extra por pestaña y por cambio, que suele ser irrelevante y a veces ni siquiera existe si la capa de datos ya deduplica peticiones idénticas en vuelo.

// Propagar invalidaciones, no estado: mensajes diminutos y sin version.
canal.onmessage = (e) => {
  if (e.data.tipo === 'invalidar') {
    store.dispatch(api.util.invalidateTags(e.data.etiquetas))
  }
}

El canal de difusión tampoco es la única tubería disponible, y cada alternativa resuelve algo que él no. El evento de almacenamiento se dispara en las demás pestañas cuando una escribe en el almacenamiento local, lo que da propagación y persistencia con la misma operación, a costa de transportar solo cadenas y de acoplarte al formato de lo que persistes. El trabajador compartido ofrece un contexto único que todas las pestañas ven, y con él la fuente de verdad deja de estar en ninguna pestaña. Y el bloqueo con nombre no transporta nada pero da lo único que ninguna de las otras da, que es exclusión mutua real para elegir quién manda.

Cierra la lista de decisiones una que se olvida siempre y produce el peor fallo de todos: qué ocurre cuando el usuario abre dos pestañas con sesiones distintas o cambia de cuenta en una de ellas. Si el nombre del canal es fijo, las dos réplicas se hablan sin comprobar si pertenecen al mismo sujeto, y una acción de la cuenta nueva llega a una pestaña que todavía muestra la anterior. La defensa es tan barata como imprescindible: incorpora el identificador de sesión al nombre del canal, o inclúyelo en cada mensaje y descarta lo que no coincida con el tuyo. Sincronizar entre pestañas es sincronizar entre réplicas de un mismo usuario, y esa condición hay que comprobarla en vez de suponerla.