DEV Community: Idan Shalem

Using react-broadcast-sync in a real app: dashboard filters across tabs

Idan Shalem — Tue, 06 Oct 2026 14:01:29 +0000

In Part 1 we found the problem: React apps quietly drift apart across browser tabs. In Part 2 we built the abstraction. Now let's actually use it.

Picture a dashboard open in two tabs. You change the status filter in one, switch to the other, and it still shows the old view. The data comes from the same API, but each tab holds its own copy of the UI state. Let's fix that with react-broadcast-sync: install, one real example, the gotchas I hit, and the few options worth knowing. The full options reference lives in the README, so I won't repeat it here.

1. Installing react-broadcast-sync

npm install react-broadcast-sync

Usage telemetry is off unless you set telemetry: true. Sync works the same either way.

There are two ways in. useBroadcastChannel(channelName, options) is a hook for one component that needs its own channel. BroadcastProvider calls the same hook once and shares the result through context, so any descendant can read it with useBroadcastProvider(). I use the provider near the root for a shared app channel.

import { BroadcastProvider } from 'react-broadcast-sync';
import Dashboard from './Dashboard';

export default function App() {
  return (
    <BroadcastProvider
      channelName="dashboard"
    >
      <Dashboard />
    </BroadcastProvider>
  );
}

Dashboard is your own component. Inside it, postMessage(type, payload) sends, and incoming payloads arrive as message.message. Open the app in two tabs on the same origin and you're connected.

2. A real-world pattern: dashboard filters

The dashboard has two controls, item status and date range. A change in one tab should update the other. I send the complete selection each time, so the receiver applies one object instead of rebuilding it from field changes.

I keep the filter shape, defaults and message name in one place:

export type Filters = {
  status: 'all' | 'open' | 'closed';
  range: '7d' | '30d';
};

export const initialFilters: Filters = { status: 'all', range: '7d' };
export const FILTERS_APPLY = 'filters/apply';

The library's postMessage takes a string type and a payload. It doesn't infer a typed protocol, and TypeScript types don't validate incoming data at runtime, so the receiver checks the values itself.

Here's the whole feature in App.tsx. The channel is dashboard with the namespace filters-v1, joined as dashboard-filters-v1. Every participating tab uses the same pair.

import { useState } from 'react';
import { BroadcastProvider, useBroadcastProvider } from 'react-broadcast-sync';
import { FILTERS_APPLY, initialFilters } from './filters';
import type { Filters } from './filters';

export default function App() {
  const [filters, setFilters] = useState<Filters>(initialFilters);

  return (
    <BroadcastProvider
      channelName="dashboard"
      options={{
        namespace: 'filters-v1',
        registeredTypes: [FILTERS_APPLY],
        onMessage: {
          [FILTERS_APPLY]: message => {
            const next = message.message;
            if (
              next &&
              (next.status === 'all' || next.status === 'open' ||
                next.status === 'closed') &&
              (next.range === '7d' || next.range === '30d')
            ) {
              setFilters({ status: next.status, range: next.range });
            }
          },
        },
      }}
    >
      <FilterPanel filters={filters} onApply={setFilters} />
    </BroadcastProvider>
  );
}

function FilterPanel({ filters, onApply }: {
  filters: Filters;
  onApply: (next: Filters) => void;
}) {
  const { postMessage, error } = useBroadcastProvider();

  function applyFilters(next: Filters) {
    onApply(next);
    postMessage(FILTERS_APPLY, next);
  }

  return (
    <section>
      <h1>Dashboard filters</h1>
      <label>
        Status
        <select value={filters.status} onChange={event => {
          const status = event.target.value;
          if (status === 'all' || status === 'open' || status === 'closed') {
            applyFilters({ ...filters, status });
          }
        }}>
          <option value="all">All</option>
          <option value="open">Open</option>
          <option value="closed">Closed</option>
        </select>
      </label>
      <label>
        Date range
        <select value={filters.range} onChange={event => {
          const range = event.target.value;
          if (range === '7d' || range === '30d') {
            applyFilters({ ...filters, range });
          }
        }}>
          <option value="7d">Last 7 days</option>
          <option value="30d">Last 30 days</option>
        </select>
      </label>
      <p>Showing {filters.status} items for {filters.range}.</p>
      {error && <p role="alert">{error}</p>}
    </section>
  );
}

The flow has two entry points. A user changes a control: applyFilters updates this tab, then sends the selection. Another tab sends a selection: onMessage validates it, then updates this tab. I broadcast in the user action and keep the incoming handler focused on applying state, so a received change never gets re-sent.

Tab A: user changes a filter
   |  applyFilters: update local state, then postMessage('filters/apply', next)
   v
BroadcastChannel 'dashboard-filters-v1'
   |
   v
Tab B: onMessage validates the payload, then setFilters(next)

What travels over the channel is a snapshot of UI state: the complete filter selection, not a stream of field edits.

In a real dashboard, filters would also feed your query or chart props. The example stops at the UI so the sync code stays visible.

Filters are rarely the only thing a dashboard syncs. Once a second feature needs to talk across tabs, you have to decide how the two share a channel.

Channel, namespace, registeredTypes

When a second feature shows up, say a theme toggle, you have three tools, and they do different jobs. The channel name plus namespace decides which tabs and hooks talk to each other: the resolved BroadcastChannel name is channelName-namespace, so dashboard with filters-v1 becomes dashboard-filters-v1. registeredTypes only filters on receive: unlisted types are dropped after they arrive.

If the types belong to one feature and the same components, keep one channel and set registeredTypes. If the features are independent, with different listeners or options, give each its own channel or namespace. With one resolved name and a hook per feature, the browser still delivers every message to both connections and the ignored ones are dropped in JavaScript. Separate channels never deliver them at all.

3. Gotchas

The browser observations below came from testing in two Chrome tabs under React StrictMode. They describe the tested setup, not every browser or app.

Broadcasting is not persistence

A tab opened later gets nothing sent before it connected. In my test a third tab started with the app defaults. Load the current selection from your normal data source.

Apply locally, then broadcast once

The sending hook doesn't get its own message back, so update local state first. Never re-broadcast what you just received. Leave sourceName generated: two tabs with the same name ignored each other in my test.

Delivery order is not a conflict policy

Two near-simultaneous edits can leave tabs with different last values. For business records the server stays authoritative.

Expiry is not app state

An expired notice vanishes from the receiver's messages, but it doesn't undo state your onMessage already set, and it stays in the sender's list. expirationDuration: 0 means no expiry.

Routing is not security

A namespace and registeredTypes pick which messages arrive. They don't validate payloads or authenticate senders. Keep the runtime checks, and never treat a channel message as authorization for a server action.

4. The options worth knowing

The README lists every option with its default. These are the ones this dashboard actually needed:

namespace: appended to the channel name (channelName-namespace) to separate features or protocol versions. Use the same pair in every tab.
registeredTypes: drops unlisted incoming types before they reach messages or onMessage. It filters on receive only. I set it on every feature channel.
onMessage: handles accepted incoming messages, as one function or a map keyed by type. It receives the envelope. React may not have rendered the new messages yet, so use the argument.
keepLatestMessage: one slot across all types, so a message of another type replaces the previous one. Good for a single latest-value stream like a theme, wrong for filters plus notices in one provider. For latest-per-type, use registeredTypes or separate channels.
telemetry: off by default. Omit it to keep usage events off; set telemetry: true only to opt in. Sync works either way.
expirationDuration on postMessage: for short-lived notices. Use a positive number of milliseconds.

The timing options (cleaningInterval, cleanupDebounceMs, deduplicationTTL, batchingDelayMs, excludedBatchMessageTypes) can wait until you have a concrete reason. Defaults were fine for me. One thing to know if you touch them: a positive cleanupDebounceMs longer than cleaningInterval can postpone cleanup indefinitely.

Recipe: tell other tabs to refresh

This is a pattern, not a feature of the library. After saving a record, send its ID as a hint. The receiver validates it and refetches through your data layer. The channel carries the hint and the server supplies the truth.

const { postMessage } = useBroadcastChannel('records', {
  registeredTypes: ['record/invalidated'],
  onMessage: {
    'record/invalidated': message => {
      const value = message.message;
      if (value && typeof value.id === 'string') {
        // Call your app's refetch/invalidation function here.
      }
    },
  },
});
// In your save handler, after the existing request succeeds:
postMessage('record/invalidated', { id: 'record-42' });

If you use TanStack Query, the comment becomes one line: queryClient.invalidateQueries({ queryKey: ['records', value.id] }).

Bonus: if a coding agent writes your code

The package ships a SKILL.md for coding agents (the agentskills.io format) and an llms.txt generated from the README. Nothing is installed automatically. If you use an agent, copy the skill into your project yourself and check where your agent reads skills from:

mkdir -p .agents/skills
cp -r node_modules/react-broadcast-sync/skills/react-broadcast-sync .agents/skills/

The README has an Agent Skill section with the details. It also helps to point your agent at the README and this post, since the gotchas above are the mistakes agents make most.

Wrapping up

We started with tabs that each lived in their own bubble. The fix turned out small: local React state for the UI, a channel that carries change notifications, a provider for a shared subtree, and separate channels when features stop sharing a protocol. Validate incoming values, update locally before sending, and decide up front how new tabs and conflicting edits should behave instead of assuming the channel handles them.

That closes the series: the problem, the abstraction, and now the use. Your tabs don't have to be isolated anymore. Try it on one filter bar, and tell me which tabs were open, what you sent and what you expected the other tab to do. The full option reference is in the README.

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 single newest message, across all types." 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!