registry: Add an API to retrieve the localName given a custom element constructor

[treshugart]

I've read the spec and I can't find any mention of how to get the localName of an element from the constructor. In v0 (I know, don't rely on old Blink) you could:

const Ctor = document.registerElement('x-test', {
  prototype: Object.create(HTMLElement.prototype)
});

// x-test
console.log(Ctor.name);

In Chrome Canary this behaves as I'd expect:

class Ctor extends HTMLElement {}
window.customElements.define('x-test', Ctor);

// Ctor
console.log(Ctor.name);

I can see why this is but I feel there's use cases for this. For example, when exporting a custom element constructor, consumers may need to know the name that it got registered with. In https://github.com/webcomponents/react-integration, we use the registered name in order to tell React the element it should create in the virtual DOM. Currently we have to construct the component and get the tagName from it.

A proposal for this may be to add a method to CustomElementRegistry which retrieves the name of the element when passed a constructor:

// any getLocalName(Function constructor)
window.customElements.getLocalName(Ctor);

It could return null if not found, or the localName if found.

Thoughts?

[domenic]

There is no way to do this. As you say, constructing the component and retrieving the .localName from it is the best way currently.

It sounds like the one use case you've provided so far is working around the fact that React cannot use normal element constructors, i.e. it insists on using createElement? Are there any other use cases that aren't working around framework-specific limitations?

[treshugart]

Yeah, React needs the local name so it can do it within the patching algorithm.

In Skate we use Incremental DOM and though it leverages the actual DOM, we still have to tell it the localName of the element to create. This information we currently store internally and pass on.

In the same library (Skate), we also offer a way to auto-generate unique tag names. This is useful if you have two versions of the same component arriving on the same page, for whatever reason. It could be someone is slowly upgrading to the new version of your component, Webpack HMR, writing tests without ensuring the component name is unique (because you can't unregister in a teardown step), etc. While this is trivial to do at the library level - and should be done at the library level - it'd be nice for integrations if there was a standard way to retrieve the localName the constructor was registered for, that way component consumer's don't have to rely on the library the component was written in to do so. To them it's just a web component, as opposed to a Skate component.

Piggy-backing off that, a more compelling use-case may be for libraries like iDOM or React to be able to check internally that if a function is passed (React already supports this as stateless functions), to see if it's a custom element constructor (maybe Func.prototype instanceof HTMLElement or something). If so, then it could do customElements.getLocalName(Func) and then do the diffing and patching. Patching could be done using the constructor if a new element is needed, however, you probably wouldn't want to create a new element to get the localName just to diff element types. Furthermore, instanceof probably wouldn't be appropriate here because Func could be a subclass of the element being compared (and this is assuming they even use real DOM nodes - iDOM does, but I don't think React and other implementations do).

There's probably other use-cases, but those are definitely ones close to our domain that we've encountered and some we use on a daily basis.

[treshugart]

I also haven't considered customised built-ins here and haven't thought about it much yet.

[rniwa]

We could add something like getName on document.customElements that gives you the name of the custom element given the constructor, which you can obtain via new.target.

[treshugart]

That'd do the trick!

[rniwa]

My proposal would be renaming the existing get to getInterface and add getName to make the semantics clear. We could even call them findInterface and findName as well.

[domenic]

The use cases still aren't clear to me; they seem very speculative, relating to things that maybe future versions of some libraries might choose to do, or to things that can already be done at the library level.

[treshugart]

I don't agree that all my use cases were speculative. If we don't have a
standardised way to retrieve a tag name for a constructor, it forces us to
store that information locally. Since part of our API is to have multiple
working versions on the page, we then force internal APIs to never change
else we break that contract. This would be a really nice feature for us to
have.

On Sat, 17 Sep 2016, 02:33 Domenic Denicola notifications@github.com
wrote:

The use cases still aren't clear to me; they seem very speculative,
relating to things that maybe future versions of some libraries might
choose to do, or to things that can already be done at the library level.

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
#566 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAIVbHhRY2qLU-gMgCDlXEdk3gdRt_yeks5qqsTNgaJpZM4J8SND
.

[treshugart]

And FWIW I second @rniwa's proposal, though get* might follow existing
conventions more closely

On Sat, 17 Sep 2016, 08:59 Trey Shugart treshugart@gmail.com wrote:

I don't agree that all my use cases were speculative. If we don't have a
standardised way to retrieve a tag name for a constructor, it forces us to
store that information locally. Since part of our API is to have multiple
working versions on the page, we then force internal APIs to never change
else we break that contract. This would be a really nice feature for us to
have.

On Sat, 17 Sep 2016, 02:33 Domenic Denicola notifications@github.com
wrote:

The use cases still aren't clear to me; they seem very speculative,
relating to things that maybe future versions of some libraries might
choose to do, or to things that can already be done at the library level.

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
#566 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAIVbHhRY2qLU-gMgCDlXEdk3gdRt_yeks5qqsTNgaJpZM4J8SND
.

[bradleyayers]

I echo @domenic's sentiment. I had a chat with @treshugart offline and suggested changing Incremental DOM to allow it to be agnostic to the element name when given a constructor.

(It seems like it should be able to do a elem.constructor === Ctor check when diffing the DOM, rather than relying on some elem.tagName === getName(Ctor) logic.

[treshugart]

Yeah, bouncing ideas off @bradleyayers helped. Though, maybe we're missing something with the theoretical implementation. I know with some built-ins this isn't reliable:

// true
document.createElement('blockquote').constructor === document.createElement('q').constructor;

In my mind it should work because you can't reuse the same class for multiple components, though I feel like I'm missing something.

[bradleyayers]

I know with some built-ins this isn't reliable

I don't think we need it to work with built-ins — it only needs to work with custom elements.

That being said, I'm interested in some concrete examples where builtins don't work as expected, and which environments are affected.