Re: [w3c/webcomponents] CustomElementRegistry.prototype.define<bulk>() (#892)

I can't immediately break down code order issues here, I can think of a different optimization this method might achieve, where a bulk definition prevent dirtiness, such as sanitization happens before an actual definition.

Let's get this initial example:

```js
customElements.define('x-foo', Foo);
customElements.define('x-bar', Bar);
```

If we assume an exception happens for the second line, e.g. `x-bar` was already defined before. I mind end up with `x-foo` defined but a different `x-bar` existing. Today, to overcome this problem I'd need to verify if all the names are valid and not defined before I define all I need for my application. In this example I'd need to verify if `x-foo` and `x-bar` are defined before I start calling `.define` for both of them. All of this considering sync execution.

The bulk definition resolves this problem with a single unified step to verify. This becomes more simple as the bulk definition method is finally reliable. 

```js
try {
  customElements.defineBulk({
    'x-foo': Foo,
    'x-bar': Bar,
  });
} catch {
  // no new definitions expected here
};
```

if one of the items is invalid or the name already exists, this method won't pollute my customElements registry.

-- 
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/892#issuecomment-684132964