Re: [w3c/webcomponents] Non-class based example of customElement.define() (#587)

I feel like it may be a bad design for the `localName` string property to be coupled to specific semantics of the JavaScript language. I like that you tried to fix the problem; it would allow the end user of the API to pass in _any valid JavaScript class_, not just ES6 classes and I think that would be very beneficial because not everyone wants to use ES6 classes all the time.

> Furthermore, it requires the HTMLElement's constructor to be called with the local name as an argument, which many people argued are unnecessary and ugly.

Definitely true, that would be ugly!

If I understand correctly, `new.target` doesn't work with ES5 classes because calling a super constructor in the form `SuperConstructor.call(this)` means that there won't be a `new.target` reference inside `SuperConstructor`, so when `HTMLElement` is used like that it won't have a `new.target` and therefore cannot look up the constructor in the custom element registry?

Maybe we can add something to JavaScript? What if we add a new method to functions similar to `Reflect.construct` and that takes a context object, and only works when the containing constructor is called with `new`.

```js
function Foo(...args) {
  HTMLElement.construct(this, args) // or similar, and new.target in HTMLElement is Foo.
}

Foo.prototype = Object.create(HTMLElement.prototype)

customElements.define('x-foo', Foo)
new Foo
```


-- 
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/587#issuecomment-271030433