Classes and interfaces

What a field declaration promises

When you write name: string inside a class, you are telling the compiler that every object created from this class has a name, and it is a string. Code elsewhere is then allowed to call shop.name.toUpperCase() without checking for undefined.

That promise has to be kept, or the guarantee is worthless. The flag that enforces it is strictPropertyInitialization, one of the checks turned on by strict. If a declared field is never assigned, the compiler stops you before the code runs.

Two mistakes this check catches

Assigning the field from another method. If the constructor calls this.init() and init assigns the field, you still get ts(2564). The compiler does not follow assignments across methods, because it cannot tell whether that method always runs. Assign the field in the constructor itself.

Reaching for ! too early. boss!: string is a definite assignment assertion: it moves the guarantee from the compiler to you. The check stops reporting, but nothing is verified. If the value is really undefined, the failure happens at runtime. Use it only where something outside the class is known to assign the field, such as a framework that injects it.

A class declaration creates two things

class Order {} creates a type named Order and a value named Order. In a type position, Order means one instance of the class. The class object itself — the thing you write new in front of — has the type typeof Order. So let a: Order holds an instance, while let b: typeof Order = Order holds the class and lets you call new b(). An interface creates only a type, never a value.

In a subclass constructor, super() comes first

If a subclass writes its own constructor, it must call super(...) before it touches this. Forgetting gives ts(2377): Constructors for derived classes must contain a 'super' call. This rule comes from JavaScript itself; TypeScript only reports it earlier.

One consequence is easy to miss. The subclass's own field initializers run after super() returns. So if a base-class constructor reads a field that the subclass initializes, it reads undefined. Anything the base constructor needs should be passed to it as an argument.

Common mistake: treating private as a security feature

A password or a token stored in a private field is not protected. One JSON.stringify(shop) prints it. So does the browser's DevTools, and so does any log line that serializes the object. #field does keep the value out of those places, but it is still plain text in memory and it is still in your bundle if you hard-coded it. Real secrets belong on a server, not in a field of either kind.

Parameter properties emit code, so they cannot just be erased

This is the one feature in this chapter with no JavaScript equivalent. Everything else here is either erased or already JavaScript, but a parameter property makes the compiler generate a this.db = db statement that is not in your source. Node's built-in TypeScript support (22.18 and later) only strips types, so it rejects this syntax. The erasableSyntaxOnly flag reports it as ts(1294) if you want the compiler to warn you first. Use parameter properties freely with a normal build step; avoid them if Node must run your .ts files directly.

A getter and its setter may have different types

Since TypeScript 4.3 the setter may accept a wider type than the getter returns, as long as the getter's type is assignable to the setter's. That is useful when you want to accept several input forms but always hand back one: set sugar(v: number | string) together with get sugar(): number lets callers write o.sugar = "30" while o.sugar still reads as a number.

Three details that are easy to get wrong

1. implements does not change the type of the class. It adds no members and it does not annotate anything for you. If you write pay(amount) { … } with no type, amount does not become number; it is an implicit any, which is an error under strict (ts(7006)). Write the parameter types yourself; the compiler then compares what you wrote against the interface.

2. abstract class vs interface. An interface only describes a shape and is erased at compile time — at runtime the name does not exist. An abstract class is a real class: it exists at runtime, it can hold implemented methods and state, and a subclass inherits them. Use an abstract class when subclasses should inherit working code; use an interface when you only want to describe a shape.

3. One extends, many implements. class Shop extends Building implements Payable, Refundable { } is valid. A class has exactly one base class, but it can be checked against any number of interfaces.

The complete rule for structural typing

Types are compared by shape, except that two types with private or protected members are compatible only if those members come from the same declaration (inherited from a shared base class counts). This is also how libraries fake nominal typing: give a class one private member, and no same-shaped stranger can be used in its place.