Re: [w3c/webcomponents] Is there a way to retrieve the localName from a custom element constructor? (#566)

Our component library has just hit a use for this, which came up during our work to support both [automatic and manual custom element registration](https://component.kitchen/blog/posts/supporting-both-automatic-and-manual-registration-of-custom-elements). Like @treshugart and others, we don’t view this issue as speculative.

As that post notes, we have a large body of code that generally works with component constructors instead of tag names. Given a constructor, our auto-registration code would like to be able to find out whether the class has already been registered. Like @thysultan, we currently `try` instantiation and then `catch` any resulting `TypeError`, and are similarly worried we’ll inadvertently catch other kinds of exceptions. It would be simpler and more precise if we could inspect whether class B has already been registered. For this purpose, asking for the component’s registered name (and simply checking for the existence of the result) seems like it would address our need and cover others.

It would seem that the discussion has reached an impasse:

* @rniwa is open to giving devs a way to retrieve the `localName` of a registered component given its constructor. He seems to prefer overloading `customElements.get` because a separate entry point would be “odd”. As I read his words, he does not appear wedded to the idea of overloading; i.e., he might accept a separate entry point like `getName`. He *does* appear fixed on his position that this API not be extended to support built-in elements.
* @domenic, in contrast, does _not_ want an overload, but _does_ require that any solution support built-in elements.
* @annevk appears flexible on the API, with a preference toward an overload and supporting built-in elements.
* I don’t see any comments from Edge.

I think we forgot to cover this at TPAC, which would have a been a good forum to hash this out. Is there room for negotiation here?

Since the main sticking point appears to be whether this must extend to built-in elements, perhaps we could pin that down first. I don’t see the case for that. @domenic: Could you summarize your thoughts on that?

-- 
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/566#issuecomment-539647628