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

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

In [Skate](https://github.com/skatejs/skatejs) we use [Incremental DOM](https://github.com/google/incremental-dom) and though it leverages the actual DOM for patching, 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 `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.

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