experiment with universal channel #22939
Conversation
…cts to both. leave serverChannel to point to main channel for backwards compatibility
There was a problem hiding this comment.
Do we make it easy to disambiguate where a channel message comes from? IIRC it was always slightly painful to figure out which iframe a message came from during composition.
Or are you imagining that as the event names will be different for events coming from the server, you really won't need to disambiguate much?
| const serverChannel = createWebSocketChannel({}); | ||
| addons.setServerChannel(serverChannel); | ||
| window.__STORYBOOK_SERVER_CHANNEL__ = serverChannel; | ||
| window.__STORYBOOK_SERVER_CHANNEL__ = channel; |
There was a problem hiding this comment.
It feels weird that both channels come from '@storybook/channel-postmessage'. Should instead we make a new '@storybook/channel-duplex' or something?
There was a problem hiding this comment.
@tmeasday perhaps in 8.0 we can simply have a @storybook/channel that can do any, with some config passed in, no need for separate packages?
I did not want to add another package.
There was a problem hiding this comment.
Appreciate that. Maybe we should rename the package then (would that be bad too?) -- or at least indicate somewhere that 'channel-postmessage' is a bit of a misnomer as this now includes 2 channels.
There was a problem hiding this comment.
Do we make it easy to disambiguate where a channel message comes from? IIRC it was always slightly painful to figure out which iframe a message came from during composition.
Or are you imagining that as the event names will be different for events coming from the server, you really won't need to disambiguate much?
This is sort of true, yes. But this is because multiple previews can emit the same message types, and then the single manager needs to reply to the originator. This problem is not really an issue where there is a 1-to-1 relationship. Event-types are just strings really, so any connected party can listen for/emit anything they want.
Any core message-types should be defined in There's always the possibility of event-types clashing.. This is why custom events should always have some unique prefix per addon. We do this for a11y-addon for example. What's the use-case for knowing if an event came from the server? |
|
I don't have any right now, so maybe it's fine :) |
An experimental branch for a merged serverChannel into postMessageChannel