This is actually more a question about the object-orientation model in ES6. However I am going to use the creation of a new custom element as an example.

So the new and shiny (as of today) method to create a new custom element is via customElements.define() which take in a tag name, a constructor, and options (which is optional) according to MDN, Google, and of course the spec. All the documentation listed uses a variation of the new class keyword for constructor.

Assuming I don't like the new class syntax, and considering for most part class is a syntatic sugar (according to this tutorial). The spec even specifically state that

A parameter-less call to super() must be the first statement in the constructor body, to establish the correct prototype chain and this value before any further code is run.

By reading the tutorial I came out with this to try if it is possible (also to revise and re-learn Javascript's object model).

var _extends = function(_parent) {
    var _result = function() {
        _parent.call(this);
    };
    _result.prototype = Object.create(_parent.prototype);
    Object.defineProperty(_result.constructor, 'constructor', {
        enumerable: false,
        writeable: true,
        value: _result
    });

    return _result;
};

customElements.define('foo-bar', _extends(HTMLElement));
console.log(document.createElement('foo-bar'));

I am getting this error

Error: The custom element being constructed was not registered with customElements.

So my question is, is it possible to do it without using class keyword (also without new if possible)? If the answer is no, should I stick to the class keyword instead of using Object.create when I write new Javascript code in the future?

This is actually more a question about the object-orientation model in ES6. However I am going to use the creation of a new custom element as an example.

So the new and shiny (as of today) method to create a new custom element is via customElements.define() which take in a tag name, a constructor, and options (which is optional) according to MDN, Google, and of course the spec. All the documentation listed uses a variation of the new class keyword for constructor.

Assuming I don't like the new class syntax, and considering for most part class is a syntatic sugar (according to this tutorial). The spec even specifically state that

A parameter-less call to super() must be the first statement in the constructor body, to establish the correct prototype chain and this value before any further code is run.

By reading the tutorial I came out with this to try if it is possible (also to revise and re-learn Javascript's object model).

var _extends = function(_parent) {
    var _result = function() {
        _parent.call(this);
    };
    _result.prototype = Object.create(_parent.prototype);
    Object.defineProperty(_result.constructor, 'constructor', {
        enumerable: false,
        writeable: true,
        value: _result
    });

    return _result;
};

customElements.define('foo-bar', _extends(HTMLElement));
console.log(document.createElement('foo-bar'));

I am getting this error

Error: The custom element being constructed was not registered with customElements.

So my question is, is it possible to do it without using class keyword (also without new if possible)? If the answer is no, should I stick to the class keyword instead of using Object.create when I write new Javascript code in the future?

• javascript
• web-ponent
• es6-class
• custom-element

1 Answer 1

In some simple situations it is possible to define a custom element without the class keyword.

The trick is to use Reflect.construct() to replace the super() call.

var CEo = function ()
{
    console.log( "created" )
    return Reflect.construct( HTMLElement, [], CEo )
}

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

CEo.prototype.connectedCallback = function ()
{
    console.log( "connected" )
    this.innerHTML = "Hello v1"
} 

customElements.define( "object-v1", CEo )

Note that it's a not a supported syntax because, as you stated, ES6 classes are a little more than just syntaxic sugar.