Incremental micro-frontend adoption

[petebacondarwin]

What do you think about the incremental adoption of micro-frontends that we demo in the productivity-suite?

[luisvieiragmr]

I think the approach is pretty good overall! i was just wondering did you think about how to properly isolate each fragment? Legacy apps often have global styles that will mess with your fragments and it seems very easy for a fragment to introduce some global css that clashes with other fragments

[dario-piotrowicz]

Hi @luisvieiragmr 👋 thanks for your comment and interest in our experiment 😄

In your comment you are mentioning css but I guess your question more generally applies to the state of the application as well?

Regarding js, for example we have seen that frameworks can add things to the window object or the document's head, these are out of our control and that is something I believe frameworks should hopefully get better at (as we've mentioned it in the Current Framework Assumptions section 🙂), we all we can do about that I think is try to apply cleanups when we can and just experiment and see what frameworks can work well together.

Regarding css, unfortunately you are correct and global css can mess up things, we reasoned that it makes sense for the fragments to respect this fact and make sure that they don't leak out (the fragments should be owned by the same team or organization that own the legacy application so it shouldn't be too problematic to enforce some conventions). This can be done via conventions such as BEM or also most of the modern frameworks offer options for scoping css. So hopefully it would not be too problematic?

One thing we've experimented with was to put fragments into shadowDoms this would help in isolating the styles but created other issues, such as frameworks not being able to correctly detect the dom elements when they are inside the shadow dom.

Another thing that would be interesting to explore is using CSS layers to provide such fragments isolation (for example we could at build or run time move all the fragments' styling in appropriate layers), that could be interesting but not water tight I think.

---

We also experimented a bit with iframes and they provided a very high level of isolation both from the js and css side of things (from my point of view you can't get better isolation than that), unfortunately they come with their own set of problems which, for our purposes outweighed the isolation benefits.

---

Anyways the assumptions/conventions I mentioned above I think are ok but require extra care from the fragments authors (and modern frameworks) and they are not fool proof, we may look into things and see if we can find better solutions moving forward 🙂, if you have any opinion or suggestion please let us know as we'd love some input on this 😃

[luisvieiragmr]

i think css can be really a pain in these architectures, i've had that experience while trying split a large application using a similar strategy and had to deal with lots of conflicts, iframes were not an option because everything needed to be SSR, and i'm not sure about the impacts on a11y.
I think the only alternative would be something like declarative shadow dom but the browser support is not there yet. Also other interesting things to consider are fonts and icons which are usually heavy assets. I used to rely on the shell app injecting those, but it also adds some coupling to the overall architecture. CSS layers seems worthy to explore 👍

[dario-piotrowicz]

Ah wow, I must admit that weren't aware of declarative shadow dom, thanks for pointing that out, I have had a look and that looks very nice! 😃 Although it wouldn't work in our case either because the issue we had with the shadowDom were not actually related to SSR.

To be actually more specific, the main issue we encountered with ShadowDom (if I remember correctly) was that in Qwik event.preventDefault calls don't work because of its asynchronous nature, so what Qwik allows the developers to do is to add an attribute to elements and use that to actually call preventDefault synchronously (as you can see in the docs). The issue is that in order to do that Qwik does a document.querySelectorAll check which doesn't go into shadowDoms, so we were loosing this functionality and were unable to for example prevent the login form submission page reload.
This was an issue we had with Qwik but I think that this sort of thing can happen with other various frameworks as well (which look into the document for elements), so that's my sort of biggest concern with ShadowDom, putting things into it has the side effect of potentially hiding DOM elements from frameworks.

---

Regarding the other aspects, you make very valid points (many of which we have encountered/considered ourselves when working on the demo). We ourselves have put some shared styles in the shell and I do find it somewhat reasonable but it does increase the system coupling. But the final result should indeed feel like a single cohesive app so some styles probably need to be shared in any case. I guess it is either a case of deciding where and how that style can be shared (putting it in the shell is just the first more intuitive solution that comes to mind).

Regarding CSS layers that is something that could work nicely but I think that it would still require care and possible conventions, for example the whole thing would breaks if !important are used, which unfortunately I think is something that devs have to sometimes use when dealing with frameworks (and their shared libraries, not to mention if they use bootstrap which, if I remember correctly has !importants all over the place)...