Having gained much experience with the implementation of various microfrontend-based solutions — I’ll try to share what I’ve learned.
This artic...
Some comments have been hidden by the post's author - find out more
For further actions, you may consider blocking this person and/or reporting abuse
This is a great article, thank you. Reading the comments, you don't need to defend yourself. Using window is fine for your examples and kept focus your point. When implementing, like you said, create your own object.
Thanks again.
Ow my I smell trouble with those approaches. It looks like the
windowobject has become the new playground...The examples should be just treated like such.
For most of these patterns you don't need to use
window. Actually, a framework like Piral does not use any globals at all. Instead, each microfrontend exports a function that gets an object as argument. This is also shown in the article in a very rudimentary implementation.There are other frameworks though, which only rely on globals. With these - I have exactly the same feeling ...
Microfrontends invention is a playground for bored feds anyways, so more 1999 patterns wont hurt ;-)
Most of the time communications can be done with a WebComponent, properties/attributes and custom events or a method on the WebComponent...not with global window magic
I think you misunderstood the point.
Unfortunately, if you use WebComponents you already introduce "global window magic" as these need to be registered globally. That's actually far more worse as you'll need to have a proper naming scheme here. For instance, you cannot register the same name twice. So two microfrontends cannot register a custom element
my-dropdown. Going beyond web components your custom events (as outlined in the article) are placed somewhere, too. Where do you add the listener here?If you need decoupling you'll need a way to decouple.
window(or any global) is one way - not the recommended way, but certainly a possibility and easy to illustrate.Also if you have a web component from microfrontend A hosted at
#mife-aand another web component from microfrontend B hosted at#mife-bhow should they reach each other? They don't know each other and as such one component cannot determine the attributes of the other.I think your comment is rather reflects that you did not really get in touch with the subject in full detail.
Why do you think passing down props and listening to events is not decoupling? It is an interface and you listen to the events on the custom element itself. Clear and straightforward. How can you even communicate if you don't know the interface of the other one?
Name collision is an issue with any of the aforementioned solutions...you need a naming convention...if you have the same names, it hurts any of them.
Why seeing something as over architected makes me look as I haven't done micro frontends before?
You cannot pass down props (or attributes) because they are both in different areas and don't know each other (otherwise see the aggregator component - there you can do exactly what you want to do but in a safe and decoupled way).
Sry I've meant attributes. You can get really far with attributes and events if the teams can agree upon the interface and doesn't change it often.
Thank you for this article, the part about APIs exposed by each frontend is gold!
thanks great article.
please fix last paragraph link to piral is broken:
https://github.com/smapiot/piralinstead ofhttps://github.com/piralThanks! Fixed!
Can we get working example of this article?
What you want / expect? Everything in this article is pretty much working.
Thanks for the immediate reply.
Component aggregation part is confusing. So looking if we have git repo so that it will make us to understand better. How this aggregator integration works in real time? I am looking for an example.
A real-world example is
Extensioncomponents in the Piral framework: docs.piral.io/guidelines/tutorials...See for an example here: github.com/piral-samples/piral-mic...
Hope that helps!
Also for extension components have a look at Dante's great article: dev.to/dantederuwe/my-experiences-...