extends Best performance way to extends a PIXI class ?

[jonforum]

Hello everyone
What is the most powerful and performance way to extends a PIXI class?
Example from my side, I need the native PIXI.Container class but with more methods and properties, and here's how i proceed.
 

PIXI.ContainerData = (function () {
    class ContainerData extends PIXI.Container {
        constructor() {
            super();
            this.Sprites = {};
            // others custom proprety for game obj
        };
        get d() { return this.Sprites.d }; // return diffuse sprites
        get n() { return this.Sprites.n }; // return normals sprites //TODO: spine normal are arrays

    };
    
    ContainerData.prototype.createJson = function(dataValues) {
        
    };

    ContainerData.prototype.asignJson = function(dataValues) {

    };

//END
return ContainerData;
})();

I also know another way to extends functional prototyping.
example:

function ContainerData() {
    PIXI.Container.call(this);
    this.initialize();
};
ContainerData.prototype = Object.create(PIXI.Container.prototype);
ContainerData.prototype.constructor = ContainerData;


ContainerData.prototype.initialize = function () {
    this.Sprites = {};
};

I wondering about the cleanest and most efficient techniques to properly extend a class pixi?
But especially on the most optimal way, knowing that JS need scan all the prototypes from the bottom to the top!

The first technique worries me a little because in my console, Is look like that all the prototypes are cloned by reference and duplicate!

 

So, i am interested in different techniques and advice.
I am therefore looking for the most equitable approach between performance (speed) but also the readability for debugging.
Thanks in advance.

[ivan.popelyshev]

Same performance.

[xerver]

They are identical. The "class X extends Y" syntax was added into ES6 as just a syntax sugar for the second snippet you posted (which was ES5).

However, you should simplify by removing the IIFE and not assigning to prototype:

    class ContainerData extends PIXI.Container {
        constructor() {
            super();
            this.Sprites = {};
            // others custom proprety for game obj
        }
        get d() { return this.Sprites.d } // return diffuse sprites
        get n() { return this.Sprites.n } // return normals sprites //TODO: spine normal are arrays

        createJson(dataValues) {
        }

        asignJson(dataValues) {
        }
    }

No need for any of that wrapper code, if you are using ES6 then just use ES6.

[jonforum]

2 hours ago, xerver said:

However, you should simplify by removing the IIFE and not assigning to prototype:

No need for any of that wrapper code, if you are using ES6 then just use ES6.

the reason why i use self invoked it because when my app boot, i want  assign to PIXI CLASS  a new type of container.
But i don't want hack the vanilla pixi , it's getting too difficult to handle in my head.
So for keep clean my workflow, i create a new js file and i hack pixi vanilla in this file, on the app boot.

The issue  with your suggestion (don't use self invoked) is that PIXI will does not inherit the new class.
The class will be global , and i don't want overload global scope.

 

in my projet contex , i wan special container for all my objs

const cage = new PIXI.CageContainer(dataBase);

and all other basic elements without game objs will be basic pixi container.

const cage = new PIXI.Container();

i don't know if you understand ? !

[xerver]

Fair enough, I would still remove the mix of es5 functions (.prototype.func = function () {}) and just use es6 functions. But it makes sense why you are using an IIFE.

Just so you know, if you use a module system like CommonJS (require('...')) or ES6 Modules (import from '...') then the bundler (Webpack, Rollup, etc) will usually wrap each of the modules in an IIFE for you. If you are just concatinating js files together then you should keep the IIFE.