Open jiwon79 opened 5 months ago
Hey there! 😁
Thanks for the great question/architectural issue you brought to the table 🎉
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:
@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.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!@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.I think you made me see a crucial point of view, which I think Monorepo Networker should receive as a few updates:
@common/network
should only be there to;
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 😁
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?
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 sidesmessage-receivers.ts
Strategy registrar on how to receive/listen to message from other sidesmessage-handlers.ts
Behavior registrar on how to handle incoming messagesentry.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
Base Idea
plugin.ts
depend on@plugin
and@common
.index.html
depend on@ui
and@common
.@common
don't depend on@plugin
and@ui
.plugin.ts
notindex.html
,Current Situation
./src/common/network/messages/CreateRectMessage.ts
plugin.ts
. Howeverplugin.ts
,index.html
are depend on it.(@common
include CreateRectMessage.ts)CreateRectAction.ts
(function that create rect to interact figma) under the@plugin
.@common
to send in UICreateRectAction.ts
,@plugin
@common
depend on@plugin
.CreateRectAction.ts
is under@common
CreateRectAction.ts
is interact with figma.Curiosity
How can I add interact figma code without depend on
@ui
? Could you please let me know if I'm not familiar with how to use themonorepo-networker
library?