Re: [w3c/webcomponents] Scoped Custom Element Registries (#716)

@tomalec one of the use cases we're trying to address is a large application that may not be able to guarantee that each tag name is used only once, whether because there are version conflicts, or because portions of the app are built and distributed separately. We see this with decentralized teams,  or with applications with plug-in systems like IDEs.

The pattern that would need to develop is that elements would be distributed without self-registering:

```js
export class MyElement extends HTMLElement {}
// no customElements.define() call
```

The user of the element imports and defines the element in the registry it's using:

```js
import {MyElement} from './my-element.js';
const localRegistry = new CustomElementRegistry();
localRegistry.define('my-element', class extends MyElement {});

class MyContainer extends HTMLElement {
  constructor() {
    this.attachShadow({mode: 'open', customElements: localRegistry});
  }
}
```

This scopes the definition so it doesn't conflict with any other registration is the entire page.

I prefer the imperative API as a start because it's an incremental change from current patterns and doesn't tie this proposal with with another. Tying the scope to the ShadowRoot is mainly because ShadowRoot is the one scoping mechanism we have in the DOM, and it makes sense that a scope will work for a number of things like CSS, element definitions, and DOM.

If there's a situation where the shadow root creator and the registry owner are different, I suspect there will usually be a way to route the registry to or from the ShadowRoot creator to be able to get the registry to the right place.

For any declarative feature we do have a problem of referencing values in JS. The current solution is exactly CustomElementRegistry: a global keyed object that's specced to be used as a lookup from a DOM value. In general I don't think we've identified a slam-dunk pattern for referencing non-global objects from markup. This came up in the Template Instantiation discussion too, for choosing template processors from markup. Once we solve that we should be able to tell a declarative shadow root which registry to use. Speculatively (and probably a poor choice of syntax, tbh) it could be something like this:

```html
<template is="declarative-shadow-root" registry="registry from ./registry.js">
  ...
</template>
```

Where `registry from ./registry.js` is like a JS import.

I think this is a separable concern though

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/webcomponents/issues/716#issuecomment-368049437