ES6 Class Syntax
debt(d5/e3/b3/t7)
Closest to 'specialist tool catches it' (d5). The detection_hints list ESLint and TypeScript as the tools. ESLint with appropriate rules can catch missing super() calls and temporal dead zone issues, but these aren't default linter catches — they require configured rules or TypeScript's stricter checking. The _ prefix for 'private' vs # private fields is a pattern-level issue a specialist tool would flag, not a compiler error.
Closest to 'simple parameterised fix' (e3). The quick_fix is clear and bounded: call super() before any this access in subclass constructors, and replace _ convention with # for truly private fields. These are targeted replacements within one component/file, not a cross-cutting refactor, but slightly more than a single-line patch since multiple constructors across a component may need updating.
Closest to 'localised tax' (b3). The applies_to scope is web and cli (broad JS contexts), but class syntax misuse tends to be contained within the class hierarchy itself. It doesn't reshape the entire codebase architecture; it imposes a tax on the component using inheritance, with limited propagation to consumers of the class.
Closest to 'serious trap' (t7). The misconception explicitly states that JS classes look like PHP classes but have fundamentally different semantics — prototypal inheritance, truly private # fields not accessible via reflection, and no interface keyword. This directly contradicts expectations from class-based OOP languages (PHP, Java, C#), making the 'obvious' mental model consistently wrong in ways that produce subtle runtime bugs.
Also Known As
TL;DR
Explanation
class, extends, super, static, constructor, get, set — familiar PHP-like syntax. Key differences: JavaScript classes are hoisted but not initialised (unlike PHP), private fields use # prefix (not access modifiers), static fields on the class not the prototype, and methods are non-enumerable. Class fields (public/private) are Stage 3+. No interfaces; use TypeScript or duck typing. super() must be called before using this in a subclass constructor.
Common Misconception
Why It Matters
Common Mistakes
- Forgetting super() in subclass constructor before using this
- Using class before its declaration (temporal dead zone)
- Expecting private fields accessible via Object.keys or JSON.stringify
Code Examples
class Animal {
name; // public field
constructor(name) { this.name = name; }
}
class Dog extends Animal {
constructor(name) {
this.bark(); // ReferenceError: must call super() first
super(name);
}
}class Animal {
#name; // Truly private
constructor(name) { this.#name = name; }
get name() { return this.#name; }
toString() { return this.#name; }
}
class Dog extends Animal {
#breed;
constructor(name, breed) {
super(name); // super() first
this.#breed = breed;
}
static create(name, breed) { return new Dog(name, breed); }
}