JavaScript Classes Practice

1. Class bodies run in strict mode, even if the surrounding code doesn't.
2. Class declarations are block-scoped like let. You can't use a class before its declaration (Temporal Dead Zone).
3. In derived constructors, super() must come before this. The base class initializes the instance first.

Most class bugs trace back to forgetting one of these.

When you pass a method as a callback, it loses its this:

class Button {
  constructor(label) {
    this.label = label;
  }
  handleClick() {
    console.log(`Clicked: ${this.label}`);
  }
}

const btn = new Button('Submit');
const fn = btn.handleClick;
fn(); // TypeError: Cannot read property 'label' of undefined

Why it happens: Assigning the method to a variable and calling it detaches it from btn. In strict mode (which class bodies always use), a bare function call sets this to undefined.

The same problem appears with setTimeout(btn.handleClick, 0). With addEventListener, the result is different but still broken: the browser sets this to the DOM element, not your class instance, so this.label silently returns undefined instead of throwing.

Fix 1: bind() in the constructor

class Button {
  constructor(label) {
    this.label = label;
    this.handleClick = this.handleClick.bind(this);
  }
  handleClick() {
    console.log(`Clicked: ${this.label}`);
  }
}

Pros: Method stays on prototype (shared across instances). Cons: Verbose; easy to forget.

Fix 2: Arrow function class field

class Button {
  label;
  handleClick = () => {
    console.log(`Clicked: ${this.label}`);
  };
  constructor(label) {
    this.label = label;
  }
}

Pros: Automatic binding; cleaner syntax. Cons: Creates a new function per instance (not shared on prototype). With thousands of instances, this matters for memory.

Rule of thumb: Use arrow fields for event handlers and callbacks. Use regular methods for internal logic called via this.method(). This callback-passing pattern is central to the Observer design pattern, where objects register handlers to be notified of state changes.

Private fields (#field) are truly private, not by convention but by language enforcement:

class BankAccount {
  #balance = 0;

  deposit(amount) {
    if (amount > 0) this.#balance += amount;
  }

  get balance() {
    return this.#balance;
  }
}

const account = new BankAccount();
account.deposit(100);
console.log(account.balance);   // 100
console.log(account.#balance);  // SyntaxError!

Key differences from regular properties

Checking for private fields (brand checks)

Sometimes you need to check if an object has your private field (for example, in a static method that accepts any object):

class MyClass {
  #internal = 0;

  static isInstance(obj) {
    return #internal in obj;  // "ergonomic brand check"
  }
}

MyClass.isInstance(new MyClass());  // true
MyClass.isInstance({});             // false

This is cleaner than instanceof when you care about the internal structure, not the prototype chain.

Inheritance lets you build specialized classes from general ones. When subclasses differ mainly in behavior (not structure), consider the Strategy design pattern as a composition-based alternative:

class Animal {
  constructor(name) {
    this.name = name;
  }
  speak() {
    console.log(`${this.name} makes a sound`);
  }
}

class Dog extends Animal {
  constructor(name, breed) {
    super(name);  // MUST call before using this
    this.breed = breed;
  }
  speak() {
    console.log(`${this.name} barks`);
  }
}

The super() requirement

In a derived class constructor, you cannot use this until super() is called:

class Broken extends Animal {
  constructor(name) {
    this.extra = 'oops';  // ReferenceError!
    super(name);
  }
}

Why? The base class constructor initializes the instance. Until it runs, this doesn't exist yet.

Calling overridden methods with super.method()

class Cat extends Animal {
  speak() {
    super.speak();  // Call parent's speak()
    console.log('...meow');
  }
}

Static methods belong to the class itself, not instances:

class User {
  constructor(id, name) {
    this.id = id;
    this.name = name;
  }

  // Factory method: validates input, returns instance
  static fromJSON(json) {
    const data = typeof json === 'string' ? JSON.parse(json) : json;
    if (!data.id || !data.name) {
      throw new Error('Invalid user data');
    }
    return new this(data.id, data.name);  // "this" allows subclass inheritance
  }

  // Utility method: doesn't need instance data
  static isValidId(id) {
    return typeof id === 'number' && id > 0;
  }
}

const user = User.fromJSON('{"id": 1, "name": "Alice"}');

When to use static:

• Factory methods (fromJSON, create, clone) -- this approach is formalized in the Factory design pattern
• Utility functions that don't need this
• Constants or configuration

Use getters/setters to expose private state safely:

class Temperature {
  #celsius = 0;

  get celsius() {
    return this.#celsius;
  }

  set celsius(value) {
    if (value < -273.15) throw new Error('Below absolute zero');
    this.#celsius = value;
  }

  get fahrenheit() {
    return this.#celsius * 9/5 + 32;
  }

  set fahrenheit(value) {
    this.celsius = (value - 32) * 5/9;  // Uses the celsius setter
  }
}

Pattern: Private field + public getter + validating setter = bulletproof encapsulation.

• MDN: Classes
• MDN: Private class features
• MDN: static
• TC39: Ergonomic brand checks