Architectural Curiosity of the Project about figma-plugin-react-vite HOT 3 OPEN

Most welcome! It was very valuable to see you provide your vision on the DX 🎉

I totally agree with it. I think a more extensible file system would be like so:

• @common
  • sides.ts ["Client", "Server", "UI"]
  • messages.ts ["createRect", "sayHello", "ping"]
• @side
  • message-transmitters.ts Strategy registrar on how to transmit/send message to other sides
  • message-receivers.ts Strategy registrar on how to receive/listen to message from other sides
  • message-handlers.ts Behavior registrar on how to handle incoming messages
  • entry.ts AppNetwork.initSide(AppNetwork.Sides.CLIENT, initTransmitters, initReceivers, initHandlers);
  • feature.ts AppNetwork.send(AppNetwork.Sides.UI, "createRect", { ... });

Not the actual implementation, but leaving @common with only the backbones and a summary of what the whole network is

from figma-plugin-react-vite.

First of all, thank you so much for quick replying my question.

@common/netork should only be there to;

• Define sides
• Define communication strategies
• Define which message are there

I absolute agree this. After solve this issue at monorepo-network, I think it would be better to changes @common/network/init.ts, sides.ts with specific logic location.

Current, there are not only what kind of Side exist but how attach and listen message(window.addEventListener("message", callback), figma.ui.on("message", callback)) in @common.

@common/network just define what kind of sides(UI, PLUGIN) there. Then, specific code that how attach and listen message are located in each package(@ui, @plugin).

What do you think about it?

from figma-plugin-react-vite.

Hey there! 😁

Thanks for the great question/architectural issue you brought to the table 🎉

Comments on your cases

I think you have valid points, which makes the architecture a bit hard to extend. 😀
Let me try to give my comment on each situation you wrote down:

1. Every message is under @common/network/messages. This was an idea heavily inspired by how Minecraft Forge's netcode works. Both sides can access it; one side uses it to be able to dispatch a "message sending" action, other side uses it to actually accommodate incoming "message" and handle it in some way. So handler in this case creates a two-way dependency on @common and any other side. I find your word valuable on this.
2. Message depending on a utility/code specific to a side. This one a very good eye-opener for me. As I never considered in monorepo-networker there might be 2 completely isolated sides. I always had commonly available sides were a matter of subject. You are so right with this one!
3. Bringing in the handling code inside @common, even tho it's not a common code. Absolute the worst architectural design we could ever do, so you're absolutely right with this one as well.

What actions should be taken?

I think you made me see a crucial point of view, which I think Monorepo Networker should receive as a few updates:

• Message receive handlers are highly side-dependent. Therefore, they should be handled on their corresponding side. As you suggested ✅
• @common/network should only be there to;
  • Define sides - Which sides are available throughout the application ✅
  • Define communication strategies - Which strategy a certain side uses to communicate with another side ✅
  • Define which messages are there - Which messages are present for a certain side ✅

I'm actually going to create this as an issue in monorepo-networker, to accommodate this very fundamental architectural problem.

Thanks a lot for enlightening me,
Feel free to share your thoughts 😁

from figma-plugin-react-vite.