Feature: serverChannel API

[ndelangen]

Introduce a new API for storybook code:

An API to send messages to and from the serverChannel from addons.
Addons can connect to the serverChannel both in manager.ts and from preset.ts files, allowing an addon to do bi-directional communication.

This is very useful for addons that want to do some work in node, like let's say:

• render something serverSide (serverside rendered languages)
• replace some file (update some config in main.ts)
• add a file (a story file perhaps (controls generating new stories)
• this list goes on...

Changes:

• Add an API for sending messages to the serverChannel from manager-api
• Add listening capability to serverChannel on node's side
• Fix data/args handling from serverChannel

[JReinhold]

Looks good to me.
Small feedback on the API:

1. Would it make sense to call it emit/onServer instead of emit/onServerAction, given that the existing is not called emitAction
2. Should we have feature parity with the regular channel, so also have offServer, onceServer, getServerChannel?

[shilman]

Can we abstract it so that there is only one channel? This feels like yet another concept to have to educate addon authors about. Instead, addons could differentiate based on the event type.

[tmeasday]

I agree with @shilman it would be best to abstract the two channels each context now has into a single "multiplexing" channel. But in the meantime, let's work to make the server channel as consistent as possible with the existing "manager<->preview" channel.

[yannbf]

I agree with Michael, if it's possible to get the same channel, then we get a nice API for addon authors, plus we get the already working mechanisms of on, off and once

[tmeasday]

This mostly LGTM. I'm a little unsure about the API naming, apart from that I agree with the approach so far.

[tmeasday]

Should we have getServerChannel also? What about equivalents of off, once, etc?

I find the names onServerAction and emitServerAction kind of awkward. What about adding an extra argument to the other functions on('server', 'event', ...) or similar? Is that too confusing?

[ndelangen]

@tmeasday I propose we do this, then later merge the 2 channels, and when we do that completely drop onServerAction and emitServerAction entirely.

So in the future .on will simply listen to both, and .emit will emit to both.

I don't want to do that today, because it would complicate/delay.

[ndelangen]

This is the "trick" to get (and possibly even modify/extend, the serverChannel: It's now a presetProperty.

This means addon creators can add a preset.js and add:

import { Channel } from '@storybook/channels';

export const serverChannel = async (channel: Channel) => {
  // do something with the channel
  return channel;
}

[ndelangen]

Would it make sense to call it emit/onServer instead of emit/onServerAction, given that the existing is not called emitAction

Should we have feature parity with the regular channel, so also have offServer, onceServer, getServerChannel?

@JReinhold @shilman I just wanted to have something that's simple and work for now, minimal approach, prove it works.

Assuming we'll later work on merging the 2 channels, do we want to add 3 more API-methods?

I'm happy to make changes, do you feel particularly strong about this?

[ndelangen]

merging the 2 channels would involve:

• making channel-postmessage also do inject a websocket transport
• modify channel lib to support multiple transports
• deal with edge cases where 1 transport is ready, the other is not (there's a buffer/flush system build-in)
• deal with edge case where the serverChannel isn't available
• update a bunch of unit-tests to cope with this change
• assess risk, might this break anything?
• edge cases of cyclical events
• edge cases of events being received multiple times

It can be done, for sure. And I think we should do it eventually.
But for a few planned projects we just need bi-directional data-flow between node<>manager.

I decided to give it a try anyway:
#22939

[ndelangen]

I'm going to close this and re-open a PR based on the same branch, so have the conversation make sense.