PHASE 6Intermediate ~22 min· topic 1 of 8

Topic 6.1

Classes with Types

In one line

A class is a blueprint that builds many objects with the same typed fields and methods. TypeScript checks that every field is declared, that every field is given a value before the object is used, and that every method is called with the right arguments.

Think of it like this

A cookie cutter. The cutter is the shape; each cookie you press out is a separate cookie with its own icing. A class is the cutter and every object made from it is a cookie. All cookies have the same shape (the same fields and methods), but one cookie can have blue icing and another pink. TypeScript is the baker who checks that every cookie really has the shape the cutter promises, and has icing before it leaves the kitchen.

Words you'll meet

New words in this topic, in plain English. Come back here whenever one feels fuzzy.

Class: A blueprint that describes the fields and methods every object built from it will have.
Instance: One object built from a class with new.
Field: A value stored on each object, like count. Also called a property.
Constructor: The special function that runs once when you write new and sets up the new object.
Method: A function that belongs to a class and works on the object it was called on.
this: Inside a method, the object the method was called on.
Initializer: A value written right on the field, like items: string[] = [];.
Definite assignment assertion: The ! after a field name, a promise to the checker that the field will be set before it is read.
Prototype: The shared object that holds a class's methods so each instance does not need its own copy.

Step by step

01Declare the fields, then fill them in the constructor

Start with a counter that adds a fixed step each time. Two fields (count and step) are declared with their types. The constructor takes the step, and sets both fields.

Notice increment() has no return type written. TypeScript works it out: it returns this.count, a number. The new keyword builds one instance, and the type of that instance is the class name.

counter.tswhole filets

class Counter {
  count: number;
  step: number;

  constructor(step: number) {
    this.count = 0;
    this.step = step;
  }

  increment() {
    this.count += this.step;
    return this.count;
  }
}

const c = new Counter(2); // c: Counter

02Forget a field and the checker notices

Add an email field but never set it. In plain JavaScript the object would simply lack the value and u.email would be undefined at some later, harder-to-find moment.

TypeScript checks the constructor and reports TS2564 on the field declaration. The message names the field and the problem exactly.

user.tswhole filets

class User {
  name: string;
  email: string; // error TS2564: has no initializer and is not definitely assigned

  constructor(name: string) {
    this.name = name;
  }
}

03Four ways to fix it

Pick the one that is honest. If a sensible default exists, write an initializer. If the value always comes in from outside, take it as a constructor argument. If the value may really be absent, mark it optional with ?. If a framework sets it later, use !.

Each choice changes what the *type* promises to the rest of your code. An optional field has type string | undefined, so every reader must handle the missing case; a ! field claims it is always there.

cart.tswhole filets

class Cart {
  items: string[] = [];  // initializer
  note?: string;         // may be missing: string | undefined
  id!: number;           // "trust me": set by load() before use

  load() {
    this.id = 7;
  }
}

04Methods, and what happens to this

A normal method uses the this of whoever calls it. Writing b.clickMethod() passes b. Pulling the method out into a variable and calling it plain passes nothing, so this is undefined in a module.

An arrow function stored in a field captures this once, when the object is built, so it can be passed around safely. TypeScript does not warn about the detached call, so you have to know this rule yourself.

Methods, and what happens to thisdiagram

Rendering diagram…

05A class is a value and a type

The name Point after new is the constructor, a value you can pass around. The name Point after a colon is the type of one instance. The constructor itself has its own type, typeof Point.

Because TypeScript compares shapes (Topic 3.5 and Topic 6.5), an object literal with the same members is also accepted where a Point is wanted.

Try it yourself

1
Fix the missing email
In the User example, change the constructor to constructor(name: string, email: string) and set this.email = email. Update the call to new User("Asha", "a@x.in"). Predict the Types panel before you look.
It becomes clean, and the console prints the email instead of undefined.
2
Make a field optional
In the User example, change email: string; to email?: string;. Predict: does the error go away? What is u.email's type now?
The class error disappears because undefined is now allowed. Hover with // ^? under u.email to see string | undefined.
3
Call a class like a function
In the last example add const p2 = Point(5, 6); and read the error before you scroll.
TypeScript says the value of type typeof Point is not callable and suggests new. At runtime JavaScript would throw Class constructor Point cannot be invoked without 'new'.

Code & diagrams

A first typed class

Two fields, one constructor, one method. The ^? shows the instance type is just the class name. The console prints the instance as Counter { ... }.

Console

(nothing was printed)

Expected console output

4
Counter { count: 4, step: 2 }

strictPropertyInitialization: a field nobody sets

TypeScript reports the problem at the field. The program still runs (like tsc, the live editor emits anyway) and prints the undefined that the error predicted. Fix it by passing email into the constructor.

Console

(nothing was printed)

Expected console output

undefined

Initializer, optional and definite assignment

The first console line is undefined: the ! field exists but nobody has set it yet, and TypeScript trusted you. The last line is an error because note is optional, so its type includes undefined.

Console

(nothing was printed)

Expected console output

undefined
7

Methods lose this when you detach them

No type errors, yet the last line prints undefined: the detached method has no object. The arrow function field kept its this. (this?. is used so the demo does not crash.)

Console

(nothing was printed)

Expected console output

OK
OK
undefined

A class is a type and a value

q is a plain object, not made by new Point, yet it is accepted: TypeScript compares shapes. The type of the class itself (the thing you call new on) is typeof Point.

Console

(nothing was printed)

Expected console output

(1, 2) q

Break it on purpose

Errors are the best teachers. Make each change, read the error, guess what went wrong, then reveal the answer.

Break #1

Misspell a field in the constructor

In the Counter example, change this.step = step; to this.stepp = step;.

terminal

$ Types panel

── what you'll see ──

index.ts(3,3): error TS2564: Property 'step' has no initializer and is not definitely assigned in the constructor.

index.ts(7,10): error TS2551: Property 'stepp' does not exist on type 'Counter'. Did you mean 'step'?

Myth vs fact

Myth

A TypeScript class is a different thing from a JavaScript class.

Fact

It is the same JavaScript class. TypeScript only adds field types, access modifiers and checks, and erases them before the code runs.

Myth

Declaring count: number; sets it to 0.

Fact

A declaration only tells the checker the field exists and its type. With modern targets it creates the property with the value undefined. Give it an initializer or set it in the constructor.

Myth

The ! after a field makes it safe.

Fact

It only silences the checker. If nothing really sets the field, the first read gives undefined where your type promised a value.

Pro corner

Extra depth for experienced readers. New to this? Skip it for now and come back later.

▸
strictPropertyInitialization needs strictNullChecks (both are part of strict). The checker follows control flow in the constructor: assigning in both branches of an if counts, assigning in a helper method called from the constructor does not (use ! or an initializer for that).
▸
useDefineForClassFields changes the emit. When it is on (default for target ES2022 and later), x!: number; becomes a real field set to undefined, and a subclass field redeclaring a parent property can overwrite what the parent constructor set. When it is off, an uninitialised declaration emits nothing at all.
▸
Methods are shared on the prototype, so a class with 10,000 instances has one copy of each method. An arrow-function field creates one closure per instance: fine for event handlers, wasteful for hot data classes.

Remember this

1
The problem this solves: Making many similar objects by hand means repeating the same fields and functions, and the copies drift apart. A class defines them once. A class is a blueprint for objects. You write it once with the fields (the values each object stores), the constructor (a special function that runs when you build an object) and the methods (functions that belong to the object). You build an object with new Counter(2); that object is called an instance. Classes are plain JavaScript (they arrived in 2015); TypeScript adds types on top and erases them again before the code runs.
2
TypeScript wants every field declared at the top of the class with its type: count: number;. In JavaScript you can invent a new property any time by writing this.count = 0; TypeScript refuses to guess, because a typo like this.cuont would silently create a new property. Declaring the fields once gives the checker the full list, so it can complain about Property 'cuont' does not exist (error TS2339, or TS2551 when it can suggest the right name) and offer autocomplete.
3
The big rule is **strictPropertyInitialization** (part of strict, so it is on in every example on these pages). It says: every field whose type does not allow undefined must get a value before the constructor finishes. A new object that has a field typed string but holding undefined is a lie the type system refuses to tell. The error is TS2564: Property 'email' has no initializer and is not definitely assigned in the constructor.
4
You have four honest ways to satisfy the rule. Give the field an initializer (items: string[] = [];). Assign it in the constructor (this.name = name;). Admit it may be missing by making it optional (note?: string, whose type becomes string | undefined) or by writing undefined into the type. Or use the definite assignment assertion id!: number;, which says "trust me, something will set this before anyone reads it" (for example a method called by a framework). The ! switches the check off for that one field, so use it only when you can name the code that does the setting.
5
Methods are functions stored once on the class (on the prototype, the shared object that all instances look up) and not copied into every instance. Inside a method, this is the object the method was called on. That is decided at the call site: counter.increment() works, but pulling the method out (const f = counter.increment; f()) loses the object and this becomes undefined. An arrow function field (click = () => this.label) is created per instance and always remembers its own object, at the cost of one function per instance.
6
A class declaration creates two things with one name. A value (the constructor function you call with new) and a type (the shape of the instances). In const c: Counter = new Counter(2) the first Counter is the type and the second is the value. The type of the constructor itself is typeof Counter. Calling a class without new is an error in TypeScript (TS2348) and also throws at runtime.
7
One detail worth knowing: with the modern target the live examples use (target: esnext), TypeScript keeps field declarations as real class fields (useDefineForClassFields is on by default for ES2022 and later). A field declared as id!: number; really exists on the object with the value undefined until you set it. Fields are also set after the parent constructor has run, a subtle order you will meet again in Topic 6.3.

Explain it without notes

What does strictPropertyInitialization check, and how can you satisfy it?

What is the difference between a class as a value and a class as a type?

Why can this be undefined inside a method, and how do arrow function fields help?

What does id!: number mean, and what is the risk?

Practice

Write a class Rectangle with width and height (numbers) set from the constructor and a method area(). Create one, log its area, and then try to read rect.color and write down the error.

This class has an error. Fix it in two different ways: once with an initializer and once with an optional field. Say how the type of tags differs between the two. ``ts class Post { title: string; tags: string[]; constructor(title: string) { this.title = title; } }

Trade-offs

↔
Classes bundle data and behaviour and give you instanceof and inheritance. Plain objects plus functions (and types from Phase 3) are lighter and easier to copy and serialise. Many TypeScript codebases use classes for services and long-lived objects, and plain types for data.
↔
Arrow function fields fix this at the price of one function per instance and methods that subclasses cannot override through the prototype.

Done when you can

I can write a class with typed fields, a constructor and a method.
I can explain strictPropertyInitialization and name the four ways to satisfy it.
I can say what this is when a method is called normally and when it is detached.
I can tell the class as a type from typeof ClassName.
I know that ! only silences the checker and that it is a promise I must keep.

Command Palette

Words you'll meet

Step by step

01Declare the fields, then fill them in the constructor

02Forget a field and the checker notices

03Four ways to fix it

04Methods, and what happens to this

05A class is a value and a type

Try it yourself

Fix the missing email

Make a field optional

Call a class like a function

Code & diagrams

Break it on purpose

Misspell a field in the constructor

Myth vs fact

Pro corner

Remember this

Explain it without notes

Practice

Trade-offs

Done when you can