Lesson 3. Prototypes and Classes

Mission link: Class syntax hides a delegation mechanism that is still there, and it surfaces in three places a typed codebase cares about: what instanceof answers, where methods actually live, and why a class instance survives serialisation as a plain object.
Primary source: You Don't Know JS Yet: Objects & Classes, chapter 5
Prerequisites: Lesson 2

Warm-up

1. ▢ const copy = { ...original } and then copy.tags.push("b"). Does original see it?

2. ▢ What does const prevent, and what does it not?

Know this

Every object has a hidden link to another object, its prototype. When you read a property the engine looks on the object, then on its prototype, then on that object's prototype, until the chain ends at null.

const base = { greet() { return "hi"; } };
const child = Object.create(base);
child.greet();                      // "hi", found on base
Object.getPrototypeOf(child) === base;   // true

Writing is not symmetrical with reading. An assignment creates an own property on the object itself and leaves the prototype untouched:

child.greet = () => "hello";        // own property, shadows the prototype's
delete child.greet;                 // the prototype's is visible again

That asymmetry, reads walking the chain and writes staying local, is the whole mechanism. Shared behaviour goes on the prototype; per-object state goes on the object.

class builds that chain for you

class Service {
  name: string;                     // per-instance
  constructor(name: string) { this.name = name; }
  describe() { return this.name; }   // on Service.prototype, shared
}

describe lives on Service.prototype, so every instance shares one function object. name is an own property of each instance. new Service("a") creates an object whose prototype is Service.prototype and runs the constructor with this bound to it.

extends links prototypes, super calls up the chain, and static members live on the constructor function rather than on the prototype.

Two class features that look alike and are not:

class A {
  method() { return this; }         // on the prototype, shared
  field = () => this;               // an own property per instance
}

The arrow field is created once per instance and captures this at construction, which is lesson 4's material and the reason it exists. It costs one function object per instance, which is why it is a tool for a specific problem rather than a default style.

What this means in practice

instanceof walks the chain. x instanceof Service asks whether Service.prototype appears in x's prototype chain. It is therefore false across execution contexts, and false for an object that merely has the same shape.

Serialisation loses the chain. JSON.parse(JSON.stringify(instance)) returns a plain object: same own properties, no prototype, so no methods. Anything arriving from a network or a file is a plain object however you typed it, which is exactly why stage 5 exists.

TypeScript is structural, and the prototype chain is nominal. The compiler will accept { name: "x", describe: () => "x" } where a Service is expected, because the members match. instanceof will still say false. The two are answering different questions, and mixing them is a common source of confusion.

Private fields are the one truly private mechanism. #field is enforced at run time by the language. TypeScript's private is a compile-time claim that is erased, so it is visible to any untyped caller.

Practice

1. ▢ Predict all four.

   const base = { kind: "base" };
   const child = Object.create(base);
   console.log(child.kind);
   child.kind = "child";
   console.log(child.kind, base.kind);
   console.log(Object.hasOwn(child, "kind"));
   delete child.kind;
   console.log(child.kind);
   

2. ▢ Where does each of these live, and how many function objects exist for ten instances?

   class Counter {
     n = 0;
     inc() { this.n++; }
     dec = () => { this.n--; };
   }
   

3. ▢ An object arrives from JSON.parse and the code calls a method on it. Predict what happens and say why the compiler did not object.

   class User { constructor(public name: string) {} greet() { return "hi " + this.name; } }
   const raw = JSON.parse('{"name":"ada"}') as User;
   console.log(raw.greet());
   

4. ▢ Which is true of x instanceof Service?

   • a) It compares the shape of x against the class
   • b) It looks for Service.prototype in the chain
   • c) It calls the constructor to compare results
   • d) It checks the value of x.constructor.name

5. ▢ You need a field that outside code genuinely cannot read, even from untyped JavaScript. Which do you use, and what is the trade-off?

Real-world reps

• [ ] Build the Counter class and check Object.hasOwn(instance, "inc") and Object.hasOwn(instance, "dec"). The pair of answers makes the prototype distinction concrete.
• [ ] Round-trip a class instance through JSON.stringify and JSON.parse, then call a method on the result and read the error.
• [ ] Tomorrow: find an as SomeClass in code you know where the value came from outside the program. Decide what would happen if a field were missing.

Going further

• You Don't Know JS Yet: Objects & Classes, chapter 5: delegation, and the case for using it directly
• You Don't Know JS Yet: Objects & Classes, chapter 4: how this interacts with all of this, which is lesson 4
• Ordinary object internal methods: the specified lookup algorithm
• Resources

Not landing? Reread the primary source at the top, since this lesson compresses it and compression is where understanding leaks. Check the glossary for any term that felt slippery.

If the lesson itself is unclear rather than the material, that is a defect: open an issue.