Feature suggestion: withTabSync

[ketchel]

Initial discussion about this feature can be found here: #289.

Adding the withTabSync extension to a store would synchronize the state between browser tabs and windows. The suggested implementation is inspired by use-broadcast-ts

Behavior

• When the state changes in one tab, it posts a message using BroadcastChannel. When a tab receives a message, it updates it's own state.
• When a new tab opens, it populates the store normally and sends the data to other tabs. This helps keep tabs converged after initialization.
• Conflict resolution: last message arrival wins (updates are applied in the order received).

Implementation

This feature could follow a similar pattern to withStorageSync.

File structure

src/lib/tab-sync/
  broadcast-channel.service.ts
  with-tab-sync.ts
  tests/

broadcast-channel.service.ts

Manages the BroadcastChannel, providing a wrapper for postMessage and closing the BroadcastChannel when the beforeunload event fires.

with-tab-sync.ts

Similar to with-storage-sync.ts but uses BroadcastChannelService instead of LocalStorageService. Provides the following config:

export type SyncConfig<State> = {
  /**
   * The name of the BroadcastChannel. Must be unique per origin.
   */
  name: string;
  /**
   * Flag indicating whether tabs should sync automatically.
   *
   * `true` by default
   */
  autoSync?: boolean;
  /**
   * Function to select that portion of the state which should be synced with other tabs
   *
   * Returns the whole state object by default
   */
  select?: (state: State) => unknown;
};

Constraints / Support

• BroadcastChannel is same-origin only so it can only be used within a single app.
• BroadcastChannel is not supported on old browsers https://caniuse.com/?search=broadcastchannel. If BroadcastChannel is not available, this extension is a no-op and logs a warning.
• If executed in a non-browser environment (e.g. SSR), this extension is a no-op and logs a warning.

Possible Improvements

• We could only send properties that are patched instead of the whole state. This would potentially improve performance and lessen the chances of conflicts.
• Add an initSync config option that specifies whether a new tab's store should be populated normally and broadcast to other tabs ('push') or from other tabs ('pull')

If the maintainers agree with the approach and it's okay with them I'd like to take a crack and implementing it :)

[rainerhahnekamp]

Thanks a lot. It really seems to be very similar to withStorageSync. Have you considered that this might be a plugin to the storage sync?

[michael-small]

Yeah, a withTabSync used like how session storage uses withStorageSync('user', withSessionStorage()) or IndexedDB withStorageSync({ key: 'user', autoSync: false }, withIndexedDB()) would be a natural plugin to add. But with that lineage and its naming scheme, the plugin would more likely be named withBroadcastChannel().

[ketchel]

Although the implementation pattern is similar to withStorageSync, I think the responsibilities are different enough that they should remain separate extensions.

withStorageSync is concerned with persistence (durability across reloads), whereas withTabSync is concerned with runtime synchronization between active browser contexts. It does not introduce persistence and does not rely on storage as a transport mechanism.

While both extensions react to state changes and propagate updates, their lifecycle and guarantees differ significantly. Keeping them separate avoids conflating persistence with cross-tab communication and keeps each extension focused on a single concern.

That said, they could still share internal utilities if there’s overlap in implementation.

I'm comfortable naming it withBroadcastChannel. I went with withTabSync initially because I don't think many people know what BroadcastChannel is, but withTabSync is a bit miseleading because it should also synchronize data across browser windows, not just tabs.

[michael-small]

Ah, that makes sense. In that case, I agree that they could share some internals where relevant, but the broadcast channel functionality would be its own feature.

I assume that a store composed of a withBroadcastChannel and withStorageSync would play well together as fine as they would independently? As long as they are able to work independently and but also potentially in sync, then I would be down.

[ketchel]

I definitely agree that they should play nicely together. One issue I forsee is that when the state updates, every tab that receives the new state would write to browser storage which may affect performance or cause strange bugs. We also need to decide whether the tabs on the receiving end of the BroadcastChannel write to sessionStorage. My instinct is that they should but we could add a config setting for that. Thanks Michael :)

[rainerhahnekamp]

But how do we make sure that those issues don’t come up, if they are both independent?

[ketchel]

It's a good question, looking at the withStorageSync implementation. I see three potential solutions, none of which I'm thrilled about:

1. Only guard against race conditions, not duplicate rewrites

There are already guards in useStorageSync that prevent operations while the state is being synced with storage. If we do something similar for withBroadcastChannel that would be sufficient to guard against weird race conditions. It won't guard against duplicate writes but that's a cheap operation. However, then the problem becomes withStorageSync may randomly log warnOnSyncing warnings when used with withBroadcastChannel.

2. withBroadcastChannel as a plugin of withStorageSync so that they're always in sync

This solution would require us to make it a plugin to withStorageSync. Once the write to storage is done useBroadcastChannel sends a small message 'sync' which causes other tabs to read from storage. If they're using sessionStorage we'd have to send the full state. However, I don't love this option because of the reasons I listed in my earlier comment.

3. Ephemeral state key

Before sending the state across the BroadcastChannel we add a new key to the state indicating that the update came from BroadcastChannel. Before writes, useStorageSync checks for this key. If it finds it, it deletes the key and returns without writing to storage. useBroadcastChannel sync is triggered by the key deletion but knows to return early.

Let me know what you think, I'm not thrilled with any of these solutions although I think I would lean towards number 3.

[ketchel]

Or another option

4. useStorageSync reads before each write to compare

If the state in storage is the same as the current state, return early. This one might be the best as there's no coupling whatsover between the two plugins, but it introduces an extra storage operation for each write