Mixins & composition

Share one ability with classes that aren't related

A class can extend another class with extends. That works well when one thing really is a special kind of another. For example, an AdminUser is a kind of User.

Sometimes, though, very different classes need the same small skill. Say a User, an Order, and an Invoice all need a toJSON() method. That method turns the object into plain data you can save or send. But an order is not a kind of user, and an invoice is not a kind of order. So extends doesn't fit.

A mixin solves this. A mixin is one small ability, such as toJSON(), that you add to a class or an object. You add only the ability the class needs. You don't make every class extend one big parent class.

There is a second way to share abilities, called composition. With composition, you build an object out of smaller parts, and the object uses those parts. You don't ask which parent class it should extend.

This lesson shows five ways to share an ability, in this order:

1. Mixin objects: copy methods from a plain object.
2. Class mixin functions: a function that wraps a class in a new class.
3. Traits: mixins that stop with an error when two names clash.
4. Composition: build an object from parts.
5. An event mixin: a real, useful ability with on, off, and emit.

It builds on the earlier Delegation vs classical inheritance lesson. Events get their own lessons later (Observer & pub/sub and Build an event emitter). Here they are just one example of an ability you can share.

The simplest mixin is a mixin object: a plain object that holds a few methods. You copy those methods into a class's prototype with Object.assign(target, source). Object.assign copies the properties of source into target.

Why the prototype? Every class has one object called its prototype, such as User.prototype. When a user object doesn't have a method itself, JavaScript looks for it there. So a method copied into User.prototype can be used by every user, old and new.

Object.assign doesn't copy everything. It copies only the source's own enumerable properties:

• Own means the property sits on the source object itself. A property the source only finds on its own prototype is not own.
• Enumerable means the property shows up when you list the object's keys. Most properties are enumerable. You can hide one with Object.defineProperty.

const inherited = { inherited() { return "not copied"; } };
const source = Object.create(inherited);
source.own = "copied";
Object.defineProperty(source, "hidden", { value: "not copied", enumerable: false });
const target = {};
Object.assign(target, source);
console.log(target.own);
console.log(typeof target.inherited);
console.log(target.hidden);

1. Line 1 makes an object with an inherited() method.
2. Line 2 makes source, with that object as its prototype. So source can use inherited(), but the method is not its own.
3. Line 3 gives source its own property, own.
4. Line 4 adds a property called hidden and sets enumerable: false, so it won't be listed.
5. Lines 5 and 6 make an empty target and copy source into it.
6. Line 7 prints copied. Lines 8 and 9 print undefined: the inherited method and the hidden property were skipped.

So put a mixin's methods directly on the mixin object. Don't leave them on its prototype, or they won't be copied.

Object.assign can copy several sources in one call. What if two of them have a method with the same name?

const First = { describe() { return "first"; } };
const Second = { describe() { return "second"; } };
const card = {};
Object.assign(card, First, Second);
console.log(card.describe());

Lines 1 and 2 make two mixin objects. Both have a method called describe. Line 3 makes an empty card. Line 4 copies First, then Second, into the card. Line 5 prints second. The second describe took the place of the first one, and JavaScript gave no warning.

The next example puts these ideas together. A User class gets three mixin objects. One of them has a getter. A getter is a property that runs a function each time you read it, written as get name() { ... }. Step through and watch what happens to the getter and to describe.

1const Serializable = {Run2  toJSON() { return { type: this.type, id: this.id }; }3};4const Labels = {5  describe() { return "mixin label for " + this.id; }6};7const GetterPack = {8  get createdLabel() { return "copied once"; }9};10class User {11  constructor(id) { this.type = "user"; this.id = id; }12  describe() { return "user " + this.id; }13}14Object.assign(User.prototype, Serializable);15Object.assign(User.prototype, Labels);16Object.assign(User.prototype, GetterPack);17const ada = new User("ada");18console.log(ada.describe());19console.log(JSON.stringify(ada.toJSON()));20console.log(typeof Object.getOwnPropertyDescriptor(User.prototype, "createdLabel").get);21console.log(ada.createdLabel);

Every property has a descriptor: a small object that describes it. For a getter, the descriptor holds the getter function under the name get. Copy the descriptor, and you copy the getter itself, not its value.

const source = {
  get label() { return "fresh"; }
};
const target = {};
Object.defineProperties(target, Object.getOwnPropertyDescriptors(source));
console.log(Object.getOwnPropertyDescriptor(target, "label").get !== undefined);
console.log(target.label);

1. Lines 1 to 3 make source with a getter called label that returns "fresh".
2. Line 4 makes an empty target.
3. Line 5 reads every descriptor of source and puts them on target.
4. Line 6 prints true: the copy still has a get function.
5. Line 7 reads target.label. The getter runs and gives fresh.

Copying descriptors keeps getters working. But it still doesn't check for two sources with the same name. The traits section below adds that check.

Mixin objects work best for small methods that stand on their own. A copied method can't use super to call the parent class's version of a method. When you need super, use a class mixin function instead.

A class mixin function is a function that takes a class and returns a new class. The new class extends the one you passed in and adds one ability. Because the result is a real class, its methods can use super to call the parent class's version of a method.

const Serializable = (Base) => class Serializable extends Base {
  toJSON() { return { ...this }; }
};

class Order extends Serializable(BaseRecord) {}

1. Line 1 makes Serializable, an arrow function. It takes a class called Base and returns a new class that extends Base.
2. Line 2 is the ability the new class adds: a toJSON() method.
3. Line 5 calls Serializable(BaseRecord). That call returns a class, and Order extends it.

Here is a complete version you can run:

class BaseRecord {
  constructor(id) { this.id = id; }
}
const Serializable = (Base) => class extends Base {
  toJSON() { return { id: this.id }; }
};
class Order extends Serializable(BaseRecord) {}
const order = new Order("A17");
console.log(JSON.stringify(order.toJSON()));
console.log(order instanceof BaseRecord);

1. Lines 1 to 3 make BaseRecord. Its constructor stores an id.
2. Lines 4 to 6 make the class mixin function. The class it returns adds toJSON().
3. Line 7 makes Order extend the class that Serializable(BaseRecord) returns.
4. Line 8 makes an order. The BaseRecord constructor still runs, so the order gets id "A17".
5. Line 9 prints {"id":"A17"}, using the added toJSON().
6. Line 10 prints true. The order is still a BaseRecord, because the new class extends it.

You can wrap one mixin inside another, like Serializable(Auditable(BaseRecord)). The innermost call runs first. So the chain of classes is:

• Order extends Serializable,
• which extends Auditable,
• which extends BaseRecord.

When you call a method, JavaScript looks in the nearest class first. If that method calls super.describe(), the call goes one class further down. Each class can add its own text when the answer comes back.

Step through the full example below. Then switch the wrapping order on line 14 and step through again.

1class BaseRecord {Run2  constructor(id) { this.id = id; }3  label() { return "record " + this.id; }4  describe() { return this.label(); }5}6const Auditable = (Base) => class Auditable extends Base {7  describe() { return super.describe() + " + audit"; }8  audit() { return "checked " + this.id; }9};10const Serializable = (Base) => class Serializable extends Base {11  describe() { return super.describe() + " + serial"; }12  toJSON() { return { id: this.id, audit: this.audit() }; }13};14class Order extends Serializable(Auditable(BaseRecord)) {}15const order = new Order("A17");16console.log(order.describe());17console.log(JSON.stringify(order.toJSON()));18console.log(Object.getPrototypeOf(Order.prototype).constructor.name);19console.log(Object.getPrototypeOf(Object.getPrototypeOf(Order.prototype)).constructor.name);20console.log(Object.getPrototypeOf(Object.getPrototypeOf(Object.getPrototypeOf(Order.prototype))).constructor.name);

The last three lines of the example print the class names in the chain. Object.getPrototypeOf(Order.prototype) gives the prototype of the class that Order extends. Its constructor.name is that class's name. When you change the wrapping order, the chain changes, and so does the text from describe().

You saw that Object.assign replaces a method with the same name and gives no warning. A trait is a mixin with a rule against that: if a name is already taken, stop with an error.

JavaScript has no trait keyword. You write the rule yourself in a small helper function, like this one:

1function applyTraits(target, ...traits) {2  for (const trait of traits) {3    for (const key of Reflect.ownKeys(trait)) {4      if (key in target) throw new Error("Trait conflict: " + String(key));5      Object.defineProperty(target, key, Object.getOwnPropertyDescriptor(trait, key));6    }7  }8}9const CanTag = { tag() { return "tag:" + this.id; } };10const CanLabel = { label() { return "label:" + this.id; } };11class Photo { constructor(id) { this.id = id; } }12applyTraits(Photo.prototype, CanTag, CanLabel);13console.log(new Photo("p1").tag());14applyTraits(Photo.prototype, { tag() { return "again"; } });

1. Lines 1 to 3: applyTraits goes through every trait, and every key in each trait. Reflect.ownKeys lists all of an object's own keys.
2. Line 4 is the rule. key in target asks "does the target already have this name?" If yes, it throws an error.
3. Line 5 copies the property's descriptor, so a getter stays a getter.
4. Lines 9 to 12 make two traits and a Photo class, then add both traits to Photo.prototype.
5. Line 13 prints tag:p1.
6. Line 14 tries to add a second tag. The prototype already has one, so the helper throws Trait conflict: tag.

A bigger trait helper could also let you rename a method, leave one out, or pick which one wins. Either way, a clash becomes a choice you make, not something that happens by accident.

You may hear the advice "composition over inheritance". It doesn't mean "never use extends". It means: build objects from small parts first. Use extends only when one thing clearly is a kind of another, and that won't change.

A factory function is a plain function that makes and returns an object. Here, two factory functions each make one part. A third one, createOrder, puts the parts together.

1function createSerializable(model) {2  return { toJSON() { return { ...model.data }; } };3}4function createEventHub() {5  const listeners = new Set();6  return {7    on(listener) { listeners.add(listener); },8    emit(value) { for (const listener of listeners) listener(value); }9  };10}11function createOrder(id) {12  const model = { data: { id, status: "new" } };13  return { ...model, ...createSerializable(model), events: createEventHub() };14}15const order = createOrder("A17");16order.events.on((status) => { order.data.status = status; });17order.events.emit("paid");18console.log(JSON.stringify(order.toJSON()));

1. Lines 1 to 3: createSerializable makes a part with a toJSON() method. That method returns a copy of the order's data.
2. Lines 4 to 10: createEventHub makes a part that keeps a list of listener functions. on adds a listener, and emit calls every listener.
3. Line 12 makes the order's data: an id and a status of "new".
4. Line 13 builds the order from the data, the toJSON() part, and an event hub called events.
5. Line 16 adds a listener that changes the order's status. Line 17 calls it with "paid".
6. Line 18 prints {"id":"A17","status":"paid"}.

No class had to extend a parent class with every ability inside it. In a test, you could pass in a different event hub and leave the rest alone.

The table below compares the four ways to share an ability. Read each row as: "this pattern adds this, works best here, and needs care here."

Now try choosing. For each situation, pick the pattern that fits best.

An event is a named moment, such as "done" when a download finishes. A listener is a function that should run when that event happens. Many different classes need events, so an event mixin is a useful ability to share. It has three methods:

• on(name, listener) saves a listener for an event name. It returns a function that removes the listener again.
• off(name, listener) removes a saved listener.
• emit(name, payload) calls every listener saved for that name, and passes them the payload value.

The methods are copied into the prototype, so every download shares them. But the listeners are saved in this._events, on each object itself. So each download keeps its own list of listeners.

1const EventMixin = {2  on(name, listener) {3    this._events ??= new Map();4    const listeners = this._events.get(name) ?? new Set();5    listeners.add(listener);6    this._events.set(name, listeners);7    return () => this.off(name, listener);8  },9  off(name, listener) {10    this._events?.get(name)?.delete(listener);11  },12  emit(name, payload) {13    for (const listener of this._events?.get(name) ?? []) listener(payload);14  }15};16class Download { constructor(file) { this.file = file; } }17Object.assign(Download.prototype, EventMixin);18const download = new Download("mixins.pdf");19const unsubscribe = download.on("done", (file) => console.log("saved " + file));20download.emit("done", download.file);21unsubscribe();22download.emit("done", "nothing logs");

The buttons call the real on, off, and emit methods from the code. Try this:

1. Subscribe both listeners.
2. Click Emit done. Both listeners run.
3. Unsubscribe one listener.
4. Emit again. Only the other listener runs.

Where you will use this

Mixins help when very different classes need the same small skill. Common examples:

• Turning objects into plain data with toJSON().
• Checking that values are valid.
• Sending events, or writing log messages.
• Letting cards, dialogs, and images be dragged.
• Checking whether a user is allowed to do something.

Pick the smallest tool that does the job:

• Use a mixin object for two or three methods that keep no data of their own and can be copied as they are.
• Use a class mixin function when the ability needs super, or when you want to wrap several abilities around one class.
• Use a trait helper when replacing a method by accident would cause bugs, so a clash should throw an error.
• Use composition when the ability keeps its own data or should be easy to swap.

To review the background, see Delegation vs classical inheritance and Objects & references.

Common misconceptions

Guess the output of each program before you run it. Use the hints if you get stuck.

const CanArchive = {
  archive() { return this.id + ":archived"; }
};
class Ticket { constructor(id) { this.id = id; } }
Object.assign(Ticket.prototype, CanArchive);
console.log(new Ticket("T1").archive());

const CanArchive = {
  archive() { return this.id + ":archived"; }
};
class Ticket { constructor(id) { this.id = id; } }
Object.assign(Ticket.prototype, CanArchive);
console.log(new Ticket("T1").archive());

class Base { name() { return "Base"; } }
const A = (BaseClass) => class A extends BaseClass {
  name() { return super.name() + "->A"; }
};
const B = (BaseClass) => class B extends BaseClass {
  name() { return super.name() + "->B"; }
};
class Final extends B(A(Base)) {}
console.log(new Final().name());

function safeAssign(target, source) {
  for (const key of Reflect.ownKeys(source)) {
    if (key in target) throw new Error("Conflict: " + String(key));
    Object.defineProperty(target, key, Object.getOwnPropertyDescriptor(source, key));
  }
}
const CanName = { name() { return "mixin"; } };
class Person { name() { return "person"; } }
try { safeAssign(Person.prototype, CanName); } catch (error) { console.log(error.message); }

function safeAssign(target, source) {
  for (const key of Reflect.ownKeys(source)) {
    if (key in target) throw new Error("Conflict: " + String(key));
    Object.defineProperty(target, key, Object.getOwnPropertyDescriptor(source, key));
  }
}
const CanName = { name() { return "mixin"; } };
class Person { name() { return "person"; } }
try { safeAssign(Person.prototype, CanName); } catch (error) { console.log(error.message); }

class Base { constructor(name) { this.name = name; } }
const Named = (BaseClass) => class Named extends BaseClass {
  label() { return "item:" + this.name; }
};
class Product extends Named(Base) {}
console.log(new Product("book").label());

class Base { constructor(name) { this.name = name; } }
const Named = (BaseClass) => class Named extends BaseClass {
  label() { return "item:" + this.name; }
};
class Product extends Named(Base) {}
console.log(new Product("book").label());

const EventMixin = {
  on(name, listener) { this.events ??= {}; (this.events[name] ??= []).push(listener); },
  emit(name, value) { for (const listener of this.events?.[name] ?? []) listener(value); }
};
class Timer {}
Object.assign(Timer.prototype, EventMixin);
const timer = new Timer();
timer.on("tick", (value) => console.log("tick " + value));
timer.emit("tick", 1);

const EventMixin = {
  on(name, listener) { this.events ??= {}; (this.events[name] ??= []).push(listener); },
  emit(name, value) { for (const listener of this.events?.[name] ?? []) listener(value); }
};
class Timer {}
Object.assign(Timer.prototype, EventMixin);
const timer = new Timer();
timer.on("tick", (value) => console.log("tick " + value));
timer.emit("tick", 1);

For each code question, ask: what was copied, and in what order? Did a name clash? Was a getter read? For class mixins, write down the chain of classes first. Each answer explains why it's right or wrong.

Key takeaways

• A mixin is one small ability that you add to classes that aren't related.
• A mixin object is a plain object of methods. Object.assign copies them into a prototype.
• Object.assign copies only own, listed properties. It replaces methods with the same name with no warning, and it turns getters into plain values.
• A class mixin function takes a class and returns a new class that extends it. Its methods can use super, and you can wrap several around one class.
• A trait is a mixin that throws an error when a name is already taken. You write that rule yourself.
• Composition builds an object from small parts. It is often simpler than a long chain of parent classes.
• An event mixin shares on, off, and emit with any class.

Up next: OOP principles in JavaScript.