There is, however, one problem with events: You only get notified in case of changes. Especially for your problem statement (sharing some global state) you'd be interested in the current snapshot when starting. So this assumes that all interested parties are already there when the state modifier starts submitting events. This, obviously, is in general not the case. Here, you'd end up with strange situations.
A more reliable solution would be to come up with events in both directions; i.e., one to get informed about the current snapshot (originating from interested microfrontends) and one to inform about changes to the snapshot (originating from the modifier).
One problem I see with the windowed-observable lib is that it hides what it changes on window. Sure, now every microfrontend can embed this and presumably it still works (if more or less compatible versions are used) but what if somebody tries to use __shared__ for other purposes.
I was gonna say this but you arrived first, good point 😉 Well, you can always come up with an unique name and document it in your overall app architecture so that no one messes up with the shared thingy. Maybe this could even be configurable in your build process as an environment variable with the build number or what not. About having a snapshot of what has happened when your micro rendered is a must, so others can track/react to already triggered events.
This was really a nice article to read. Looking forward to more of your content.
Hum... to solve it those keys/namespaces could be wrapped in another package which exposes only the communication API, and every micro-frontend uses this API
@florianrappl
it's a fair point, but at a certain point don't you have to simply trust the developers and hope that you hired the right people? Also, I think documentation, training, and on-boarding at the company should help tell people that you only communicate between microfrontends through the use of the recommended library (i.e. don't touch/read directly from window, use the library instead).
Really nice article - well done!
There is, however, one problem with events: You only get notified in case of changes. Especially for your problem statement (sharing some global state) you'd be interested in the current snapshot when starting. So this assumes that all interested parties are already there when the state modifier starts submitting events. This, obviously, is in general not the case. Here, you'd end up with strange situations.
A more reliable solution would be to come up with events in both directions; i.e., one to get informed about the current snapshot (originating from interested microfrontends) and one to inform about changes to the snapshot (originating from the modifier).
One problem I see with the
windowed-observablelib is that it hides what it changes onwindow. Sure, now every microfrontend can embed this and presumably it still works (if more or less compatible versions are used) but what if somebody tries to use__shared__for other purposes.Thanks again!
I was gonna say this but you arrived first, good point 😉 Well, you can always come up with an unique name and document it in your overall app architecture so that no one messes up with the shared thingy. Maybe this could even be configurable in your build process as an environment variable with the build number or what not. About having a snapshot of what has happened when your micro rendered is a must, so others can track/react to already triggered events.
This was really a nice article to read. Looking forward to more of your content.
@vbarzana This kind of comment made my day, I'll try to create more content for sure!
Unfortunately it's not so easy. The name has to be known by the microfrontends which are build and deployed independently.
Hum... to solve it those keys/namespaces could be wrapped in another package which exposes only the communication API, and every micro-frontend uses this API
I'm glad you liked it ❤️
Yep that's the main problem using the window someone may interfere in those keys 😥
@florianrappl it's a fair point, but at a certain point don't you have to simply trust the developers and hope that you hired the right people? Also, I think documentation, training, and on-boarding at the company should help tell people that you only communicate between microfrontends through the use of the recommended library (i.e. don't touch/read directly from window, use the library instead).
Nice work @luistak