CustomElementRegistry.define() should return the new custom element

[rpivo]

If calling customElements.get() returns undefined, and if we want to immediately set the custom element afterward, we would have to do something like:

    let registeredElement = customElements.get(element);
    if (!registeredElement) {
      customElementRegistry.define("text-element", Text, { extends: "p" });
      registeredElement = customElements.get(element);
    }

If CustomElementRegistry.define() returned the defined element, we could instead do:

    let registeredElement = customElements.get(element);
    if (!registeredElement) {
      registeredElement = customElementRegistry.define("text-element", Text, {
        extends: "p",
      });
    }

Or:

const registeredElement =
  customElements.get(element) ??
  customElementRegistry.define("text-element", Text, { extends: "p" });

[dominiccooney]

Very nice idea, how did we miss this?

@domenic What's the best place for this issue... Here? whatwg/html?

[markcellus]

Hmm this confuses me. define() doesnt create any element, just registers the ability to create custom elements from registry. So there wouldn't be an element to return. Or do you mean it should return the constructor?

[rniwa]

Hmm this confuses me. define() doesnt create any element, just registers the ability to create custom elements from registry. So there wouldn't be an element to return. Or do you mean it should return the constructor?

I think the proposal is to return the second argument. I'm a bit hesitant to adding something like that because it closes the possibility of future extensions to define. e.g. We have proposals / discussions for lazily defining custom elements: #782. We may decide that the way to do that is to let define accept a Promise as the second argument.

[dominiccooney]

Hmm this confuses me. define() doesnt create any element, just registers the ability to create custom elements from registry. ... do you mean it should return the constructor?

Yes. The example code makes it clear the proposal is to return the constructor.

We have proposals / discussions for lazily defining custom elements: #782.

Don't those proposals suggest a new entrypoint for lazy definitions? But to be conservative, sure, maybe resolve #782 first and then do this.

[domenic]

In general on the web platform this "chaining" style, where modifier functions return one of their arguments, is discouraged. If you have the argument already, having two ways to get it---the value you passed in, and the return value---just makes for unreadable code.

In particular, the OP seems based on the misconception that customElements.get() returns something special. It does not. In the example given it just returns Text, which the code already has access to.

[rpivo]

@domenic you are right -- I misunderstood that Text would be the same returned value as the argument passed in.

In any case, it would be nice if there was some kind of getOrSet API here. If a custom element is already defined, and if I don't want an error to be thrown, I have to wrap a customElements.define() call in a try/catch.

I can also call customElements.get() first to see if that gets anything, and if it doesn't, then call define() (edit: this patterns seems pretty common - GitHub's open source web components do this: https://github.com/github/clipboard-copy-element/blob/main/src/index.ts#L14-L17).

This is similar to the TC39 emplace proposal, which also lists some similar APIs in other languages: https://github.com/tc39/proposal-upsert

[rpivo]

Coming back to this -- I've changed my mind and think this should be closed since the error thrown from customElements.define() is valuable information. The pattern I suggested here hides that information.