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

It is true that if you're using Babel and polyfill, then the above code won't work out-of-box but that's true of any polyfill that got written before the standard is finalized.

There are various ways to workaround such issues, and probably the simplest solution is to wrap the thing you pass to `customElements.define` with a class. e.g.

```js
function defineCustomElementInBabel(name, legacyConstructor) {
    var wrapperClass = class extends legacyConstructor {
        constructor() {
            var newElement = new Reflect.construct(HTMLElement, [], wrapperClass);
            legacyConstructor.call(newElement);
            return newElement;
        }
    };
    customElements.define(name, wrapperClass);
}
```

Obviously, this leaves `new TestElement` non-functional.  An alternative approach is to replace `super()` call in `TestElement` by something special like:

```js
class TestElement extends HTMLElement {
    constructor () {
        constructCustomElement(TestElement);
    }
```
with
```js
function constructCustomElement(newTarget) {
        Reflect.construct(HTMLElement, [], newTarget);
}
```

There are dozens of other ways to cope with this limitations and that's really up to framework and library authors.

On a broader note, I don't think the standards process or API design in standards should be constrained by polyfills written before the general consensus on the API shape has been reached and at least two major browser engines have implemented it.  Also, deploying a polyfill on production before the standards have become stable is almost always a bad idea.

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