Notes on TypeScript

Top and Bottom Types

Unlike Anything or Any in most static typed languages, any supports the same operations as a value in JavaScript and minimal static type checking is performed. TypeScript's unknown is more similar to Any (top type) in other languages.

TypeScript's bottom type is never, which is called Nothing in some languages.

 1const verifyCasesAreExhaustive = (kind: "x" | "y" | "z") => {
 2switch (kind) {
 3    case "x":
 4        return 1
 5    case "y":
 6        return 2
 7    case "z":
 8        return 3
 9    default:
10        const nothing: never = kind
11        throw(nothing)
12}
13}

Function Overloads

Considering the following definition:

 1function plus(x: number, y: 0): boolean;
 2function plus(x: number, y: number): number;
 3function plus(x: string, y: string): string;
 4// function plus(x: number, y: string): boolean;
 5// function plus(x: string, y: number): boolean;
 6function plus(x: number | string, y: number | string): number | string | boolean {
 7    if (typeof x == "number" && typeof y == "number") {
 8        if (y === 0) {
 9            return false
10        } else {
11        return x + y;
12        } 
13    } else if (typeof x == "string" && typeof y == "string") {
14        return `${x}${y}`; // equivalent to `x + y`.
15    } else {
16        return false;
17    }
18}
19
20In early versions of TypeScript (e.g. [v3.5.1]),
21the following code gives misleading error information:
22
23```typescript
24plus("1", 0)
25// error: Argument of type '0' is not assignable to parameter of type 'string'.

Readers may wonder why TypeScript does not match ("1", 0) against plus(x: number | string, y: number | string).

However, recent versions of TypeScript (e.g. v5.3.2) provides clearer message:

1plus("1", 0)
2// The call would have succeeded against this implementation,
3// but implementation signatures of overloads are not externally visible

Type Equality

With TypeScript's conditional types, testing type equality is intuitive:

1type EqEq<T, S> = [T] extends [S] ? ([S] extends [T] ? true : false) : false
2
3type FunctionOverloadsEquality = EqEq<
4    { (x: 0, y: null): void; (x: number, y: null): void },
5    { (x: number, y: null): void; (x: 0, y: null): void }> // true
6
7type F = (x: 0, y: null) => void
8type G = (x: number, y: string) => void
9type FunctionIntersectionEquality = EqEq<F & G, G & F> // true

The Crazy satisfies Operator

Below is the example given in What's New in TypeScript 4.9:

 1type Colors = "red" | "green" | "blue";
 2type RGB = [red: number, green: number, blue: number];
 3const palette = {
 4    red: [255, 0, 0],
 5    green: "#00ff00",
 6    bleu: [0, 0, 255]
 7//  ~~~~ The typo is now caught!
 8} satisfies Record<Colors, string | RGB>;
 9// Both of these methods are still accessible!
10const redComponent = palette.red.at(0);
11const greenNormalized = palette.green.toUpperCase();

IMHO, this shows the craziness of TypeScript. Why green is encoded as hex string but red and blue are encoded as RGB arrays? What if one day someone refactors the code and change green to an RGB array? And in real world application, I would rather make all colors encoded as hex strings or RGB arrays, but not a mix of them. Then the getComponent or displayHex will be implemented assuming input is either a hex string or an RGB array.