Scoped custom element registries

Developer use cases

• We're running a micro frontend architecture with parts of the page composed from different teams' apps at runtime. The parts are independently deployed, and isolated today using a declarative shadow DOM boundary. We also have a shared design system with a web components base. Since every part of the micro frontend shares the global custom element registry, to update the design system when there are breaking changes requires a huge coordination effort that scoped custom element registries would solve.

  We're running a micro frontend architecture with parts of the page composed from different teams' apps at runtime. The parts are independently deployed, and isolated today using a declarative shadow DOM boundary. We also have a shared design system with a web components base. Since every part of the micro frontend shares the global custom element registry, to update the design system when there are breaking changes requires a huge coordination effort that scoped custom element registries would solve. [see original comment]
• I have the same use case as above at a cross organizational level at Adobe. It's a major headache not having Scoped Custom Element Registries. But also another use case within a single application that can create dependencies in multiple different versions of a design system within the same app for reasons of reproducibility (consistent reproduction of an old ux even though a new version is available).

  I have the same use case as above at a cross organizational level at Adobe. It's a major headache not having Scoped Custom Element Registries. But also another use case within a single application that can create dependencies in multiple different versions of a design system within the same app for reasons of reproducibility (consistent reproduction of an old ux even though a new version is available). [see original comment]