Phase 2 (After MVP): CustomElementRegistry.prototype.define() reform

[caridy]

As part of the discussions around scoped registries, @leobalter suggested an interesting idea to facilitate defining a batch of components rather than one-by-one.

Example

customElements.define({
    'x-foo': Foo,
    'x-bar': Bar,
});

Backwards compatibility

At the moment, the first argument must be a "valid custom element name", which fails for regular objects that will stringify to [object Object].

Semantics

When an object is provided that doesn't stringify to a valid custom element name, each enumerable property names can be validated as valid custom element names, and their respective value to be a valid custom element constructor. If at least one of them fails, no registration will occur, and an error will be thrown.

[snuggs]

@caridy CustomElementRegisry

[justinfagnani]

This would be a welcome feature even for the global registry. We've had users hit problems when trying to define multiple elements that interact (ie. children firing events to register with parents). They end up being sensitive to the registration order. There's also a performance concern with multiple tree walks to register multiple elements. Bulk registration would help with both.

I think this issue should be opened on the w3c/webcomponents repo though, since this is about the existing global registry.

[leobalter]

There is a small catch here, the first argument is cast to string if the function receives two arguments:

customElements.define({toString() { return 'my-foo'; }}, Foo); // valid

While, in this case, this suggestion would be valid only if one argument is given:

const obj = {
  'my-foo': Foo
};
customElements.define(obj); // should be valid

In this case, we'd need to make sure the obj is treated similarly as it would in Object.entries(obj), capturing only the "Enumerable Own Property Keys".

---

Edit: This reminds me another issue. How do we fit in the options? This might be challenging.

[leobalter]

I think this issue should be opened on the w3c/webcomponents repo though, since this is about the existing global registry.

Agreed. This issue is not dependent to Scoped Custom Elements Registry, even if both are nice combined.

[caridy]

I'm fine with moving it, @justinfagnani since you're the owner of this repo, you should see the transfer button on the right hand side. Otherwise we have to open a brand new and close this one.

[leobalter]

I'm closing this one in favor of WICG/webcomponents#892