Introducing Scoped Custom Element Registry for components using polyfill

[crav710]

Idea

As a follow up to the discussion #3556 for adding static version property which helps the component libraries to make decision on how to handle the version mismatches. But there are scenarios where SWC components depends on other SWC components, to avoid conflicts component need to internally define using scoped element registry.

To solve this we would like to add support for Scoped Custom Element registries such that it's opt-in for ace-spectrum. For Implementing it a npm package like [@lit-labs/scoped-registry-mixin](https://www.npmjs.com/package/@lit-labs/
scoped-registry-mixin?activeTab=readme) could be used which creates scoped registry for the class & also passes the registry to attachShadow().

I spent some time to try to come up with an implementation for sp-action-bar using the above polyfill:: https://github.com/adobe/spectrum-web-components/compare/crav710/scoped-registry?expand=1 . This creates a custom registry for ActionBarScoped which also defines the elements it internally uses to the scoped registry you can see that in the screenshot provided below sp-action-bar-scoped shadow-root has customElement defined within it scope. This enables us to use multiple version of same element on the same page.

ScreenShot::

Open Question

A point of consideration here is determining the optimal location for these scoped components & loading the polyfill. Currently, they are placed within the packages/action-bar/ inside a separate folder. There could be two viable options: one is to keep them into a separate folder other than packages, and the other is to consider creating a new package. @Westbrook @benjamind What are your thoughts on this? cc:: @rickharris

[Westbrook]

@crav710 et al, this issue was brought up when reviewing the progress on Scoped Custom Element Registries with implementors today. Essentially the idea that an element that is constructed abstractly (possibly by a renderer like React) will not know the registry of which it is intended to be a part. Do you see this being an issue in your projects adopting Scoped Custom Element Registries, when/if they're fully adopted in SWC?

[Westbrook]

Further discussion in this issue.

Separately, the Chrome team has asked for expanded experimentation with the prototype implementation of the underlying API here. We should definitely work to find resourcing for reviewing this work via the ScopedCustomElementRegistry flag or all Experimental Web Platform Features on so that the polyfill was no needed.

[crav710]

@Westbrook Thanks for sharing I will have a look at it and get back if the issue is a valid case for projects.
Agree on getting this done behind a feature flag.