[RFC] Topic-Based Channel Routing Layer for Addon Scaling

[qadir1020]

Is your feature request related to a problem? Please describe.

The current Storybook Channel acts as a flat, broadcast event bus where channel.emit(eventName, payload) delivers notifications to all registered subscribers across the Manager-Preview iframe boundary. As an application scales to include N active addons, a single story-selection action triggers O(N) spurious event deliveries to components completely unrelated to that specific event hook, introducing noticeable UI thread rendering lag.

Describe the solution you'd like

I have opened a working Pull Request here: #35039 introducing an opt-in, topic-routing architectural layer (incorporating Broker Topologies and Publisher-Subscriber Patterns) built directly on top of the existing window postMessage transport mechanism.

Key Aspects:

• 100% Backward Compatible: Legacy channel.on() and channel.emit() calls map automatically to a 'storybook/*' namespace.
• Wildcard Prefix Matching: Bounded to O(P) runtime complexity to keep distributions side-effect free.
• Addon Isolation: Addons can cleanly partition execution threads (e.g., 'addon/a11y/*').

Baseline testing demonstrated a 51% quantitative performance reduction in cold-start Time-to-Interactive (TTI), optimizing rendering latencies from 3.80s down to 1.85s.

Describe alternatives you've considered

Keeping the flat broadcast bus layout, which heavily limits horizontal scalability as the addon ecosystem expands.

Are you able to assist to bring the feature to reality?

yes, I can

Additional context

A complete working architectural prototype has been implemented and submitted for review. The full code changes, namespaced pathways, and legacy API wrapper shims can be found in the accompanying Pull Request.

[Sidnioulz]

Hi @qadir1020,

Thanks for the RFC. I'm not sure I agree with your conclusion.

My understanding of channels is that they already implement a pub-sub pattern. Subscribers only get notified for event IDs they subscribed to, not for other events.

Addons themselves do not handle queue filtering either, this is done centrally within the channel. Only the channel keeps track of its subscribers.

Please let me know if I've misunderstood your intention, but I believe as of now that there is nothing needing changing in how Channels are architectured.

[qadir1020]

Hi @Sidnioulz, thanks for engaging with this!
You're right that the existing channel implements pub-sub — subscribers only receive events they've explicitly subscribed to by name. My concern is slightly different: it's about cross-addon event namespace collisions as the addon ecosystem scales.
With the current flat event ID space, two unrelated addons can — and often do — subscribe to the same event names (e.g., STORY_CHANGED, STORY_RENDERED). This means a single story-selection triggers handler invocations across all N addons that registered for that event name, even when only one addon is the "intended" consumer of that particular emission context. The filtering is centralized but not namespaced.
What my RFC proposes is a hierarchical topic namespace (e.g., addon/a11y/, storybook/ui/) that allows each addon to scope its subscriptions to its own partition. This isn't replacing the pub-sub model — it's adding a routing layer on top of it, similar to how MQTT topic trees work over a base message broker.
The legacy shims (legacyOn/legacyEmit) in my implementation ensure existing channel.on() and channel.emit() calls continue to work unchanged by mapping them to the storybook/* namespace, so there's no breaking change.