DEV Community: Idan Shalem

Building React Multi-Tab Sync: A Custom Hook with the BroadcastChannel API

Idan Shalem — Wed, 06 Aug 2025 18:46:02 +0000

Ever opened two tabs of your React app and watched them slowly drift out of sync? Maybe a logout in one tab doesn’t register in the other. Or a filter change in one view disappears in the second. It's not a bug in your code - it's a blind spot in how most apps handle state.

In Part 1 of this series, I broke down why this happens - and how the browser's native BroadcastChannel API offers a solid solution for syncing tabs without a backend.

But actually using BroadcastChannel in a React app? That’s where things get tricky. My early attempts were simple - a quick useEffect here, an event listener there - but they unraveled fast. Lingering listeners, duplicate actions, messy message state. It quickly became clear: a reliable abstraction needed more thought.

This post walks through the journey of building react-broadcast-sync, a custom hook designed to make multi-tab communication seamless in React. From message deduplication to smart batching and lifecycle management, here’s everything I had to solve - and how I did it.

The Initial Approach: Learning the Limitations
Redundant Processing: A Distributed System Headache
Managing Message Lifecycles: Expiration and Cleanup
Optimizing for Volume: Batching High Frequency Messages
Tracking Who Sent What: The Source ID
Focusing on Current State: Keeping Only the Latest Message
Tuning In: Filtering by Message Type
Hands On Control: Utility Methods for Messages
Simplifying Integration: BroadcastProvider
Making It Bulletproof: Thorough Testing
Real World Use Cases
What’s Next

The Initial Approach: Learning the Limitations

Like many devs, my first instinct was to toss BroadcastChannel into a useEffect and call it a day.

import { useEffect, useRef } from 'react';

function useInitialBroadcastChannel(channelName: string) {
  const channelRef = useRef<BroadcastChannel | null>(null);

  useEffect(() => {
    const channel = new BroadcastChannel(channelName);
    channelRef.current = channel;

    channel.onmessage = event => {
      console.log('Received:', event.data);
      // Problem: If the component unmounts, we’ve got a ghost listener hanging around.
    };

    return () => {
      // Uh-oh: If we forget to close the channel, we risk memory leaks.
      channel.close();
    };
  }, [channelName]);

  const postMessage = (data: any) => {
    channelRef.current?.postMessage(data);
  };

  return { postMessage };
}

This worked fine for basic tests - until I tried it in a real app. That’s when the cracks started to show.

Two major issues popped up:

Leaky listeners: Channels weren’t always cleaned up on unmount.
Stale state: React callbacks often referenced outdated data.

It became clear that I needed a more React-friendly abstraction - one that understood lifecycles, state, and isolation.

Redundant Processing: A Distributed System Headache

When you're syncing tabs, you're essentially building a distributed system. And one annoying problem pops up fast: double-processing.

Example: Tab A logs the user out and broadcasts it. Tab B receives the message and logs out too. But what if Tab A also reacts to that broadcast? You get a double logout - or worse, an error.

Even though BroadcastChannel doesn’t echo messages back to the sender, your logic might still be wired to react to all incoming events - including your own.

The Fix: Message IDs and Source IDs

To make smart decisions, each message gets:

A unique id
A source ID identifying the tab that sent it

Now, tabs can ignore messages from themselves and skip anything they’ve already seen.

channel.onmessage = event => {
  const { id, type, source } = event.data;

  if (source === myTabId) return; // ignore my own messages
  if (isRecentlyProcessed(id)) return; // skip duplicates

  if (type === 'logout') {
    logout();
  }
};

With this, actions like logout or sync are processed once and only once per tab - even under race conditions.

Managing Message Lifecycles: Expiration and Cleanup

Some messages - like “user is typing…” or “temporary alert” - shouldn’t live forever. But by default, BroadcastChannel messages aren’t stored at all, so I was persisting them in state. The problem? That state grew forever.

The Fix: Expiration + Cleanup Interval

Each message can now include an expirationDuration. Behind the scenes, a cleanup timer runs periodically to remove expired messages from state.

postMessage('notification', { text: 'You’re connected!' }, { expirationDuration: 5000 });

The hook checks and removes stale messages every few seconds, keeping your app lean and snappy.

Optimizing for Volume: Batching High Frequency Messages

When syncing typing data or drag events, I noticed major UI jank. Turns out, spamming postMessage() dozens of times per second is a bad idea.

The Fix: Batching with Optional Bypass

I added a batchingDelayMs config. Instead of sending each message immediately, the hook groups them within a short window, then sends them as a batch. You can also exclude specific types from batching.

const { postMessage } = useBroadcastChannel('typing', {
  batchingDelayMs: 50,
  excludedBatchMessageTypes: ['form_submit'],
});

Now, typing updates stay smooth - and critical actions still go through instantly.

Tracking Who Sent What: The Source ID

The source field turned out to be more than just a way to skip my own messages. It became a powerful way to attribute updates and target logic.

Examples:

Show which tab sent the latest filter change
Detect if a message came from a different device
Ping active tabs and get their IDs

const latest = getLatestMessage({ source: 'tab-abc-123', type: 'theme_change' });

Every message now has traceability - great for debugging or building smarter features.

Focusing on Current State: Keeping Only the Latest Message

Sometimes, history doesn’t matter - only the latest state does.

If your component only cares about the current dashboard filters or online status, why store 50 updates?

The Fix: `keepLatestMessage` Mode

This mode tells the hook: "Only keep the newest message of each type." Cleaner state, simpler logic.

const { getLatestMessage } = useBroadcastChannel('filters', {
  keepLatestMessage: true,
});

You still get getLatestMessage() for querying, and you avoid managing long message arrays.

Tuning In: Filtering by Message Type

As the app grew, channels got busier - carrying everything from user presence to theme toggles. But not every component cared about every message.

The Fix: `registeredTypes`

Specify which message types you want. The hook silently ignores the rest.

const { messages } = useBroadcastChannel('app-state', {
  registeredTypes: ['theme_change', 'notification'],
});

Less noise, fewer re-renders, cleaner code.

Hands On Control: Utility Methods for Messages

While automatic cleanup is great, sometimes you need manual control - like clearing a specific notification or resetting state.

Exposed Utilities:

getLatestMessage() - grab the newest message by filter
clearReceivedMessages() - remove specific messages
clearSentMessages({ sync: true }) - delete sent messages and notify others
clearAllReceivedMessages() - wipe it clean

clearSentMessages({ types: ['notification'], sync: true });

Powerful tools, available when you need them.

Simplifying Integration: BroadcastProvider

Managing channels manually across components got tedious fast. I was duplicating hook logic and prop-drilling channel methods.

The Fix: React Context

With <BroadcastProvider>, you define a shared channel once and access it from anywhere.

<BroadcastProvider channelName="global">
  <App />
</BroadcastProvider>

Then in any nested component:

const { postMessage, getLatestMessage } = useBroadcastProvider();

Clean, centralized, and idiomatic.

Making It Bulletproof: Thorough Testing

To make this robust, I built a full test suite using a mocked BroadcastChannel. It simulates tabs, message delivery, cleanup timing, deduplication, batching - the whole thing.

Each feature was tested in isolation and under stress to ensure consistent behavior across tabs and edge cases.

If you're curious, the repo has full test coverage and examples you can learn from or extend.

Real World Use Cases

These features are now powering real multi-tab sync scenarios:

Counters and input fields synced live across tabs
Theme changes reflected instantly everywhere
Logout from one tab propagates to all others
Filter syncing across dashboards
Shared draft editing in real-time

It’s fast, simple to integrate, and battle-tested.

What’s Next

This post was all about the engineering behind the hook. In the final post of the series, I’ll walk through:

Installing react-broadcast-sync
Real-world usage patterns
Demos and gotchas
Advanced config and recipes

Live demo: react-broadcast-sync.vercel.app
npm: react-broadcast-sync
GitHub: IdanShalem/react-broadcast-sync

Stay tuned - and if you’ve got ideas, questions, or cool use cases, I’d love to hear them!

React Multi-Tab Desync: Uncovering The Forgotten Problem with BroadcastChannel API

Idan Shalem — Mon, 09 Jun 2025 19:27:24 +0000

You’ve tested your app across browsers, devices, and screen sizes. It handles slow networks, aggressive typing, and even partial form input. But have you tested what happens when a user opens a second tab?

Here’s a real story.

A colleague once complained that our internal admin panel was acting strangely. He’d opened two tabs: one to view logs, another to manage users. He made a config change in the first tab, but it didn’t reflect in the second. Then he logged out from the second tab, thinking he was done - but the first tab stayed logged in and allowed actions for another ten minutes.

This wasn’t a bug in the feature. It was a bug in the assumption that one tab is all that matters.

The truth is: in modern web apps, multi-tab usage is the norm. People open new tabs to multitask, compare, or keep context while exploring other parts of the UI. And most of the time, we as developers ignore that.

Until something breaks.

The Forgotten Problem
The Hidden UX Cost
Why React Doesn’t Solve This
Limitations of storage and postMessage
BroadcastChannel API
Why It’s Rarely Used
Coming Up in Part 2

The Hidden UX Cost of Multi-Tab Desync

When each tab is out of sync with the others, subtle and serious issues start to appear:

A user logs out in one tab, but another tab still thinks they're authenticated and keeps making API calls
A notification shows up twice, once in each tab
A local draft is saved in one tab, and then overwritten by an older state from another
A filter applied in one view is missing in another, leading to confusion

These aren’t just technical issues. They erode trust. They create support tickets. They make users feel like your app is unreliable, even if your backend and UI code are solid.

The root of the problem is surprisingly simple: browser tabs don’t share state. And most frontend frameworks, React included, don’t offer any solution out of the box.

Why React Doesn’t Solve This

React provides excellent tools for managing state within a tab: useState, useReducer, the Context API, or external stores like Redux or Zustand. But all of these live entirely inside the JavaScript runtime of a single browser tab.

Each tab gets its own React app instance, with isolated memory and state. That means even if you’re using the same global store or persist your data in localStorage, each tab still runs independently, unaware of changes happening elsewhere.

Let’s walk through a common example: logging out.

You may think you’ve got it covered:

// AuthContext.js
const AuthContext = createContext()

export const AuthProvider = ({ children }) => {
  const [isLoggedIn, setIsLoggedIn] = useState(() => {
    return localStorage.getItem('token') !== null
  })

  const logout = () => {
    localStorage.removeItem('token')
    setIsLoggedIn(false)
  }

  return (
    <AuthContext.Provider value={{ isLoggedIn, logout }}>
      {children}
    </AuthContext.Provider>
  )
}

Now, imagine this:

Tab A logs in → stores token in localStorage
Tab B opens later → reads token from localStorage → thinks user is logged in
Tab A logs out → removes token → updates its state
Tab B? Still thinks user is logged in

To fix this, one might try using the storage event:

useEffect(() => {
  const handleStorage = (event) => {
    if (event.key === 'token' && event.newValue === null) {
      setIsLoggedIn(false)
    }
  }

  window.addEventListener('storage', handleStorage)
  return () => window.removeEventListener('storage', handleStorage)
}, [])

That helps - if the logout happens via localStorage. But there are caveats:

storage events don’t fire in the same tab that made the change
It’s fragile - what if multiple values need to be synced? Manual sync logic must be implemented for each feature

This becomes even harder when dealing with more complex state - filters, drafts, modals. storage events can’t support real-time sync for everything. And even when used creatively, they amount to a custom messaging system layered on top of a key-value store.

Another messaging option is window.postMessage, which enables communication between Window objects, including iframes or tabs opened via window.open. For example:

// Tab A opens Tab B
const newTab = window.open('/another-tab')
newTab.postMessage({ type: 'init' }, '*')

// In Tab B
window.addEventListener('message', (event) => {
  console.log(event.data)
})

This works well when one tab opens the other and maintains a reference. However, it breaks down in common multi-tab use cases where tabs are opened independently (e.g., via bookmarks, navigation, or external links). Without a reference to the target Window, there is no way to initiate communication. Moreover, the opened tab can’t reliably send messages back unless it uses window.opener, which may be null due to browser restrictions or security settings. For this reason, window.postMessage is not suitable for general-purpose multi-tab communication.

React, for all its strengths, wasn’t designed with multi-tab coordination in mind.

The BroadcastChannel API - A Native Tool Worth Knowing

To address the problem of isolated browser tabs, modern browsers provide a built-in solution: the BroadcastChannel API. It enables communication between different browsing contexts, including tabs, windows, and iframes, under the same origin. This makes it an ideal candidate for implementing real-time synchronization without requiring a backend or external service.

Using BroadcastChannel is straightforward. A named channel is opened, and any tab that posts a message to that channel immediately triggers onmessage listeners in other tabs.

const channel = new BroadcastChannel('auth-channel')

channel.postMessage({ type: 'logout' })

channel.onmessage = (event) => {
  if (event.data.type === 'logout') {
    // log out in this tab as well
  }
}

Messages are transmitted almost instantly. Unlike localStorage-based communication, there is no need to serialize strings or rely on passive change listeners. Any serializable object can be sent through the channel, and tabs listening on the same name will receive the broadcast.

The simplicity of this interface is appealing. It is native, fast, and requires no third-party tools. It also avoids many of the limitations of alternatives like storage events, which are less consistent across browsers and harder to manage reactively.

However, once this API is introduced into a React application, new challenges emerge - not because of the API itself, but because of how it fits (or fails to fit) into component-based architectures.

So Why Isn’t BroadcastChannel Used More Often?

While the BroadcastChannel API offers a clean, native solution for inter-tab messaging, integrating it into a React application reveals several architectural tensions.

React’s component model encourages scoped, lifecycle-driven logic. Components mount, update, and unmount independently, often driven by state or route changes. In contrast, BroadcastChannel is a long-lived, process-level resource. Using it directly within component effects can lead to unintended side effects.

A typical integration might look like this:

useEffect(() => {
  const channel = new BroadcastChannel('auth-channel')

  channel.onmessage = (event) => {
    if (event.data.type === 'logout') {
      logout()
    }
  }

  return () => {
    channel.close()
  }
}, [])

At first glance, this seems sufficient: a single useEffect creates the channel, listens for messages, and cleans up when the component unmounts. However, this approach assumes that:

The component is always mounted when relevant messages are sent
No other parts of the app are listening to the same channel
All messages should be handled the same way, regardless of context or origin

In larger applications, these assumptions often break.

Consider a case where two tabs send a logout message at the same time:

channel.postMessage({ type: 'logout' })

channel.onmessage = (event) => {
  logout() // Gets called twice in each tab
}

If the component is conditionally rendered, the channel might be closed before a message arrives. If multiple components create the same channel, each will subscribe independently, leading to overlapping listeners and unpredictable behavior.

There is also no built-in support for tracking the source of a message, which makes it impossible to distinguish between messages originating from the current tab and those from others:

channel.postMessage({ type: 'update-settings' })

channel.onmessage = (event) => {
  applyUpdate(event.data) // Executes in the sender tab too
}

To build something reliable, developers must implement:

Message deduplication
Cleanup logic tied to React lifecycles
Source tracking
Scoped message handling
Expiration and filtering logic

Because this infrastructure is non-trivial and error-prone, most teams avoid using BroadcastChannel directly or use it only in isolated scenarios. For reliable multi-tab sync in production, a React-friendly abstraction is needed - one that wraps this API safely and integrates with the component model.

TL;DR

Most modern apps ignore what happens when users open multiple tabs. This leads to subtle bugs and broken UX, especially in React apps where state is isolated per tab. While the BroadcastChannel API provides a native solution, integrating it into a React architecture safely requires careful design. This post breaks down the problem and paves the way for a React-friendly abstraction coming in Part 2.

Coming Up in Part 2

🔔 Part 2: Building React Multi-Tab Sync: A Custom Hook with the BroadcastChannel API Subscribe or follow to get notified!

DEV Community: Idan Shalem

Building React Multi-Tab Sync: A Custom Hook with the BroadcastChannel API

Table of Contents

The Initial Approach: Learning the Limitations

Redundant Processing: A Distributed System Headache

The Fix: Message IDs and Source IDs

Managing Message Lifecycles: Expiration and Cleanup

The Fix: Expiration + Cleanup Interval

Optimizing for Volume: Batching High Frequency Messages

The Fix: Batching with Optional Bypass

Tracking Who Sent What: The Source ID

Focusing on Current State: Keeping Only the Latest Message

The Fix: `keepLatestMessage` Mode

Tuning In: Filtering by Message Type

The Fix: `registeredTypes`

Hands On Control: Utility Methods for Messages

Exposed Utilities:

Simplifying Integration: BroadcastProvider

The Fix: React Context

Making It Bulletproof: Thorough Testing

Real World Use Cases

What’s Next

React Multi-Tab Desync: Uncovering The Forgotten Problem with BroadcastChannel API

Table of Contents

The Hidden UX Cost of Multi-Tab Desync

Why React Doesn’t Solve This

The BroadcastChannel API - A Native Tool Worth Knowing

So Why Isn’t BroadcastChannel Used More Often?

TL;DR

Coming Up in Part 2

DEV Community: Idan Shalem

Building React Multi-Tab Sync: A Custom Hook with the BroadcastChannel API

Table of Contents

The Initial Approach: Learning the Limitations

Redundant Processing: A Distributed System Headache

The Fix: Message IDs and Source IDs

Managing Message Lifecycles: Expiration and Cleanup

The Fix: Expiration + Cleanup Interval

Optimizing for Volume: Batching High Frequency Messages

The Fix: Batching with Optional Bypass

Tracking Who Sent What: The Source ID

Focusing on Current State: Keeping Only the Latest Message

The Fix: keepLatestMessage Mode

Tuning In: Filtering by Message Type

The Fix: registeredTypes

Hands On Control: Utility Methods for Messages

Exposed Utilities:

Simplifying Integration: BroadcastProvider

The Fix: React Context

Making It Bulletproof: Thorough Testing

Real World Use Cases

What’s Next

React Multi-Tab Desync: Uncovering The Forgotten Problem with BroadcastChannel API

Table of Contents

The Hidden UX Cost of Multi-Tab Desync

Why React Doesn’t Solve This

The BroadcastChannel API - A Native Tool Worth Knowing

So Why Isn’t BroadcastChannel Used More Often?

TL;DR

Coming Up in Part 2

The Fix: `keepLatestMessage` Mode

The Fix: `registeredTypes`