Issue with Global Custom Element Registry Updates Affecting Multiple Microfrontend Apps

[iamravisankar]

Hello,

We have encountered a challenge with our web application architecture and are seeking guidance or a potential solution.

Context:

• We have developed a web component library using Lit, which we refer to as octa-elements.
• Additionally, we are utilizing Nx Angular for our web application, which incorporates octa-elements.
• Our web application consists of over four microfrontend apps, each running on different ports.
• All of these microfrontend apps make use of the octa-elements library.
• Each product is released separately, as they are distinct entities.

Issue:

• We have observed that when we release an update to one product (for example, App 3), the octa-elements components are inadvertently updated across all applications.
• This issue seems to stem from the fact that web components are defined globally in the Custom Element Registry.

Attempted Solutions:

• We have tried implementing @open-wc/scoped-elements and the Scoped CustomElementRegistry polyfill.
• While we are able to achieve scoped elements within another Lit element parent, we are unable to do so for independent components. For instance, octa-icon cannot be defined multiple times with different scopes.

Request:

• We are looking for advice on how to handle this situation where we need to define the same web component multiple times across different microfrontends without them conflicting due to the global scope.
• Any suggestions or guidance on how to properly implement scoped elements for independent components in this microfrontend architecture would be greatly appreciated.

Thank you for your time and assistance.

[Westbrook]

Can you expand on this:

For instance, octa-icon cannot be defined multiple times with different scopes.

This seems contrary to the concept of scoped elements.

[iamravisankar]

Hello @Westbrook,

Thank you for your response. I apologize if my initial explanation was not clear. Let me elaborate on the issue we are facing with octa-icon and the concept of scoped elements.

The core of our problem lies in the reusability of the octa-icon component across multiple microfrontends. Each microfrontend is intended to operate independently, potentially with different versions of octa-icon being used simultaneously. This is where the challenge arises.

With the standard Custom Element Registry, once a custom element is defined, it is registered globally and cannot be redefined. This global registration is causing conflicts when different versions of octa-icon are needed for separate microfrontends.

The @open-wc/scoped-elements approach allows for defining custom elements in a scoped manner, theoretically enabling the same element to be defined with variations within different scopes. However, our implementation experience has shown that while we can utilize scoped elements within a parent Lit element, we struggle to apply this scoping to independent components that are not encapsulated by a parent. Specifically, we cannot seem to define octa-icon with different scopes directly within our microfrontends.

Here's what we are trying to achieve:

Microfrontend A uses octa-icon v1.0
Microfrontend B uses octa-icon v2.0
Both versions should be able to coexist without conflict within the same application ecosystem.
We are looking for a way to define octa-icon in such a manner that it respects the boundaries of each microfrontend's scope, allowing for multiple versions to coexist without overriding each other in the global registry.

I hope this clarifies our situation. If you have any insights or suggestions on how we can overcome this hurdle, it would be greatly appreciated.

[Westbrook]

That does help clarify what you're running into.

If I understand correctly, while you have various micro-frontends, some of them are now encapsulated in their own shadow root. This would definitely point to a place where scoped custom element registries would not support the delivery of your content. If you are not able to encapsulate each micro-frontend in its own shadow root, then you would need more invasive techniques to allow for multiples of the same element on the page. This would involve changing the tag name of the elements that share the same DOM tree but not the same micro-frontend. We do not currently vend tools to support that, but if you are already shipping your code in a way that supports scoped element registries, then your consumers should be free to register their usage in a custom tag name. It's annoying, but without the encapsulation of shadow boundaries, I'm not sure what else could be done to support your use case.

[thepassle]

Cant you just wrap your microfrontend in a custom element?