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.

Okay, but worrying about cases in which your custom element's local name had already been used by someone else doesn't seem like a common scenario to me. Also, this could be trivially implemented like this:

```js
for (elementClass of elementsToRegister) {
    if (customElements.get(elementClass.name))
        throw Error;
}
for (elementClass of elementsToRegister)
    customElements.define(elementClass.name, elementClass);
```


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