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

## Questions:

* when you talk about "inheritance", do you mean "hierarchy" instead?
* is `parent` exposed somehow in a custom element registry? or is it just an internal slot of some sort?
* can you clarify the use case for exposing `CustomElementRegistry.prototype.getRegistry(name: string)`
* is there a way to know when a name is being defined in a particular registry?
* when a new entry is registered in the global registry, and 10 other registers are depending on it (waiting to be upgraded), what's the process to upgrade them all? Is there a booking process somewhere?

## Missing features

* Today, with the global registry, there is no way to intercept the usage of a particular tag, which forces application to load them all during the booting process, or do some sort of book keeping on each template to load what they needed as dependencies. I wonder if we can have some sort of hook at the registry level to tell you when an tagName is being used, so you can decide what to do, go fetch it and register it, register it from another registry, etc.
* Having to have a lineal chain of registries might be insufficient, and harder to use (this about the namespacing use-case where components in the same namespace can see/use each other, while some namespaces will have some hierarchical organization).

## Recommendation

Based on those two possible missing features, and extensibility point of view, it is probably easier to find an API that delegates part of the resolution to user-land, and let users to implement the hierarchical/resolution algo. e.g.:

```js
class MyFoo extends HTMLElement {}

// lookup must return a registry
function lookup(registry, name) {
    if (name === 'my-bar') {
        return customElements; // delegate the lookup to another known registry (in this case the global registry)
    }
    if (name === 'my-baz') {
        registry.define('my-baz', class extends HTMLElement {}); // define inline
    } else {
        // import `name` component, and define it in `register` when it is ready...
    }
    return registry;
}
const myRegistry = new CustomElementRegistry(lookup);
myRegistry.define('my-foo', MyFoo); // you can still prime the registry
```

This will require effectible a new constructor with a single argument, nothing else. Or could potentially be fold into `ShadowRoot` constructor as well. 

## Wish List

* fully composable registry graph where the resolution of a name can be delegated to any registry where the logic can be customized in user-land.
* the ability to introspect into the resolution mechanism to support mocking, lazy fetching and registration, custom resolution rules.
* preserve the semantics of the current registry to lower the friction for implementers (being realistic here).

-- 
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-350401726