Conversation
|
This should not be the default, right? Most events will still be local to the tab. Do we need a second emit for these cross-tab events? |
This comment was marked as resolved.
This comment was marked as resolved.
|
cc @ShGKme |
For some events the context is local. E.g. for a sidebar opened event. |
It seems that most (or just many) of events are local. Even with global events, it may not work globally, depending on a local data. (mentioned in the PR as complex data issue). Or the opposite. It works globally, but each tab emits the event, like
Examples are very "pseudo", but it is very related on the usage. |
There was a problem hiding this comment.
🚀🚀🚀
I think, using the Broadcast channel is a great option, that may improve many things in UX and performance / load.
In some cases moving to a "global" approach would probably require also a data sync or moving some modules to a Shared Worker or Web Locks API to implement Leader pattern. And this update in the event hub is a great start to change the way we work with updates in many apps, and to make it uniformly.
Looking forward for this update 🚀
Signed-off-by: John Molakvoæ <skjnldsv@protonmail.com>
2c1f52f to
a65c5e3
Compare
This is a first DIRTY try to support cross-tab event sharing.
Here you can see it work in action (see the favorites list in the navigation):
Peek.27-04-2023.14-42.mp4
Refs
Issues:
e.g. I was emitting a
files:legacy-view:initializedwiththisas data, and thetry...catchdidn't prevent it from failing. You will get afailed to execute 'postMessage' on 'BroadcastChannel'@ChristophWurst @nickvergessen @juliushaertl (feel free to loop anyone you'd like to discuss this)