ES6: Am I using Classes & Mixins Correctly in JavaScript?

Question

I have been learning about ECMAScript 6 Classes, Mixins and other features for the past few days, but I'm not sure if my understanding of use cases is correct. Below is a snippet of an example with Classes, Subclasses and Mixins.

class Person{
    constructor (opts){
        for(let prop of Object.keys(opts)){
            this[prop] = opts[prop];
        }
      Person.count++;
    }

    static count = 0;
}

//Greeting Mixin
const Greetings = Person => class extends Person{
    sayHello(){}
}

//Job Mixin
const Jobs = Person => class extends Person{
    getJobs(){}
    getSalary(){}
    setJobs(){}
    setSalary(){}
}

//Subclass
class WorkingPerson extends Jobs(Greetings(Person)){
    constructor(opts){
        super(opts);
        //this.type = 'nice';
    }

    sayHello(){
        if(this.type == 'nice') 
            console.log(`Hello there! Wonderful day isnt it?`);
        else
            console.log(`Ah! Get out of here!`);
    }

    getJobs(){
        return this.jobs;
    }

    setJobs(...jobs){
        this.jobs.push(jobs);
    }

    getSalary(){
        return this.salary;
    }

    setSalary(salary){
        this.salary = salary;
    }
}

let wp = new WorkingPerson({name:'Ajay',jobs:['Digital Evangelist'],salary:10000});
let wp2 = new WorkingPerson({name:'Ron',jobs:['Entertainer'],salary:20000});
let wp3 = new WorkingPerson({name:'Morris',jobs:['Televangelist'],salary:30000});
console.log(`Number of people = ${Person.count}`);

There are no errors in the code above and I get the correct output. However, are my implementations of Mixins semantically correct? Does it make sense to have a Jobs and Greetings Mixin for the given context? I read a blog Mixins and Javascript: The Good, the Bad, and the Ugly. in which they define mixins as abstract subclasses. Looking at the examples, they added small functionality to a given class. Since this sounded similar to the definition of a Decorator, I looked the difference up to the accepted answer of Python: Use of decorators v/s mixins? .It says:

Mixins add new functionalities. Decorators are used to modify existing functionalities.

This got me thinking if the Jobs and Greetings are Mixins, then what example would you give for a decorator in this context? If I am wrong in any way, please provide code blocks of the correct answer.

Also, is there a better way to supply input arguements instead of throwing some raw object as a parameter while instantiating a WorkingPerson?

Answer 1

No, mixins are not applied correctly.

Person => class extends Person{...} is basic inheritance and it can be achieved accordingly:

class GreetingPerson extends Person {
    sayHello() {...}
}

If there are multiple unrelated classes that are supposed to have the same set of methods, consider applying composition over inheritance principle.

For the rest of the cases (e.g. polymorphism that cannot be refactored in accordance with mentioned principle) mixins can be applied to either prototype:

function mixin(obj) {
  return function (target) {
    for (const key of Object.getOwnPropertyNames(obj))
      if (key !== 'constructor')
        target.prototype[key] = obj[key];
    return target;
  }
}

class GreetingBeing {
  sayHello() {...}
}

const Person = mixin(GreetingBeing.prototype)(class Person extends Biped { ... })

// or for ES.Next,
// @mixin(GreetingBeing.prototype)
// class Person extends Biped { ...}

or instance:

class Person extends Biped {
  constructor()
    super();
    Object.assign(this, GreetingBeing.prototype);
  }
}

Notice that mixin helper/decorator doesn't do multiple inheritance. All it does is copying own enumerable properties from GreetingBeing.prototype to Person.prototype)

Answer 2

Hmm..aren't decorators a proposal still? Could be wrong here but I thought this might be a future state (oh the speed at which we need to keep up...)

My understanding is this: in your context, say you wanted "jobs" to be read only. A decorator could fit the bill.

Something like:

function readonly ( target, key, descriptor ) {
    descriptor.writable = false;
    return descriptor;
}

// import the decorator function
import { readonly } from 'my-decorators';

class Person {
  @readonly
  person ( ) { return this.user; }
}

So we're modifying the behavior of that property here as implicitly read only, as opposed to hiding it in closures and whatnot. I also guess that now this property is inspectable as a "read only" property, such that it could appear in an IDE code assist dialog as read only (which is kind of cool).

One VERY good language to look for to understand mixins is Scala. The language itself may not be your thing, but mixins are an important and widely used part of the language. That's where I got my primary understanding anyway and it seemed effective. A less rigid, more flexible notion than straight OOP inheritance and such.

Great question I love exploring this stuff. You must be enjoying that class.