Mixins & composition

Share abilities without forcing a family tree

Classes are great when one thing truly is a special kind of another. But real programs often have abilities that cross family lines. A User, an Order, and an Invoice might all know how to serialize themselves. None of them is a kind of the others.

A mixin shares a small ability across unrelated classes. Instead of making every class inherit from one giant base class, you apply only the ability it needs. This lesson goes deeper than the earlier Delegation vs classical inheritance lesson: we will use classes, prototypes, super, conflict checks, and a live event mixin.

We will use five tools in order: mixin objects, class mixin functions, traits, composition, and an event mixin. Later lessons named Observer & pub/sub and Build an event emitter go much deeper on event architecture; here, events are a practical example of reusable behavior.

The smallest JavaScript mixin is a plain object full of methods. You copy those methods onto a class prototype with Object.assign. Because prototypes are shared, every existing and future instance can find the copied methods through normal method lookup.

This leans on the shallow-copy behavior from the Objects & references lesson: Object.assign copies own enumerable properties. It does not deep-copy hidden state, and it does not ask whether replacing a property is safe.

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);

Mixin objects are best for small, independent abilities. If a method needs to call super, affect construction, or cooperate with another wrapper, reach for a class mixin function instead.

A class mixin function receives a base class and returns a new subclass. It is wrapping paper: put any class inside, and the outside class adds powers while still using normal extends, method lookup, and super.

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

class Order extends Serializable(BaseRecord) {}

Stacking is just function calls around a class: Serializable(Validatable(Base)). The wrapper nearest the final class is searched first. If each wrapper calls super.method(), the call travels down the prototype chain and each layer can add its part on the way back.

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 generated classes are real classes. The replay uses Object.getPrototypeOf(Order.prototype) to reveal their constructor names. That is why changing the wrapper order changes the chain and changes the final describe() text.

JavaScript does not have a built-in trait keyword. When JavaScript developers say “trait”, they usually mean a mixin-like ability with stricter rules: conflicts must be resolved deliberately instead of overwritten by accident.

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"; } });

The important line is the guard: if (key in target) throw .... A production trait helper might let you rename, exclude, or explicitly choose a winner. The point is the same: conflicts are part of the API, not a surprise hidden in copy order.

“Composition over inheritance” does not mean inheritance is banned. It means: prefer small parts that collaborate unless a true subtype relationship is obvious and stable. Mixins themselves are a kind of composition at the class level, but object factories can make the parts even more explicit.

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()));

Here, the order owns plain data, a serializing part, and an event hub. No class needs to pretend it is a child of a SerializableEventedBase. In tests, you can swap the event hub or serializer without rebuilding a class hierarchy.

When you are choosing a design, sort the situation first.

An event mixin is a practical ability sticker: many unrelated classes may need on, off, and emit. The methods store listeners on this, so each instance gets its own listener map while sharing the same prototype methods.

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 playground calls real listener functions. Subscribe both listeners, emit done, unsubscribe one, and emit again. You are not simulating output cards; you are exercising the same on, off, and emit methods shown beside the buttons.

Where you will use this

Mixins show up whenever an ability cuts across a tidy inheritance tree: serialization, validation, event emitting, logging, caching, drag behavior, permission checks, or test helpers. The professional habit is not “use mixins everywhere”; it is “share the smallest honest ability”.

• Use a mixin object for two or three stateless methods that can be copied as-is.
• Use a class mixin function when the ability needs super, wraps a base class, or should be stacked.
• Use a trait helper when accidental overwrites are dangerous and conflicts should fail loudly.
• Use composition when the behavior has its own state or should be swapped independently.

Link only when the lesson exists: for earlier background, revisit Delegation vs classical inheritance and Objects & references.

Common misconceptions

Every choice explains the trade-off, so read the feedback even when you are right.

Key takeaways

• Mixin objects are ability sticker packs copied onto prototypes or objects.
• Object.assign is shallow, overwrites silently, and flattens getters.
• Class mixin functions return subclasses, so they can use super and stack in a visible prototype chain.
• Traits are mixins with conflict rules you define deliberately.
• Composition builds from parts and is often clearer than adding ancestors.
• An event mixin can share on, off, and emit across unrelated classes.

Up next: OOP principles in JavaScript.