reveal.js

This is an interactive presentation. Press "s" to open the speaker view.

10 Things You Did Not Know TypeScript Could Do

Hadrien Milano

Software Engineer, UI

Once in a while I'll see a piece of code which, although it works, could be improved.

[3 slides]
So I set out to the task of improving it. I come up with a simple plan.

And quickly I find that there is more to it than I initially thought.

So I iterate and work around the different complications.

After a while I end up with a monstruosity of TypeScript hacks and tricks to do just that one thing I wanted to do.
I submit it for code review and then...
My coworkers ask me to burn that code to hell.

Focus of this talk

Foundations

Types + JavaScript = TypeScript

JS with types

let someNumber = 1; someNumber = '2';

TS adds types to variables to maximize correctness of the code.
This is valid JavaScript, but it's not valid TypeScript. TS, by default considers that variables don't change type.
Notice that the error could be either in the first or the second line.
Maybe I want this variable to be a number. Or I want it to be a string, or both!
If I want both, I should write

let someNumber: string | number = 1;

When I don't write any type annotation, TS infers the type from the right hand side.

Type aliases

type MyString = string; const someString: MyString = 'abc';

Object types

type User = { age: number; name: string; isHuman: boolean; };

Define a variable:

const user: User = {
    age: 5,
    isHuman: false,
    name: 'wall-e'
}

TS helps with auto-completion.
TS has a built-in concept for these object types: an interface.

interface User { ... }

Operators

Intersection (mixins)

declare function getUser(): any; type User = { username: string; } type Admin = { admin: true } type Moderator = { moderator: true } let john: User & Admin & Moderator = getUser()

Trick #1
Safe html strings.

declare function escapeHtmlString(s: string): string; declare function getUserInput(): string; type SafeString = string & { __isEscaped: true }; function sanitize(raw: string): SafeString { return escapeHtmlString(raw) as SafeString; } function render(template: string, ...args: SafeString[]) { /* ... */ }

And this leads us to our first trick!
As you know protecting against XSS is hard. It's easy to miss a spot, but one breach is enough to compromise your app's security.

__isEscaped is a "pseudo type" or "virtual type". It doesn't exist at runtime.

const userName = sanitize(getUserInput());
render("Hello %name%", userName);

Trick #1½

declare function escapeHtmlString(s: string): string; declare function getUserInput(): string; type SafeString = string & { __isEscaped: true }; function sanitize(raw: string): SafeString { return escapeHtmlString(raw) as SafeString; } function html(body: TemplateStringsArray, ...args: string[]): string { let builder = ''; // ... return builder; } const userName = getUserInput(); html`Hello ${userName}!`; // "Hello John!"

                        This is a JS tagged template. In TS they are type-checked! 

                        Replace argument string[] with SafeString[] .

Union

type User = { handle: string; }; type Admin = { admin: true }; type Moderator = { modo: true }; declare function getUser(): any; function anyone(who: Admin | User) { /* ... */ } let john: Admin = getUser(); anyone(john);

Trick #2
Type narrowing

interface HumanUser { kind: 'human'; firstname: string; lastname: string; } interface BotUser { kind: 'bot'; handle: string; } type AnyUser = HumanUser | BotUser; function greet(user: AnyUser): string { }

This union is discriminated by the member "kind".

In the function, the only accessible member is "kind".

If I discriminate based on this value, I gain access to the other members!

if (user.kind === 'human') {
    return `Hello ${user.firstname} ${user.lastname}!`;
} else {
    return `0101000110 ${user.handle}`;
}

Trick #3
Exhaustive matching

interface HumanUser { type: 'human'; firstname: string; lastname: string; } interface BotUser { type: 'bot'; handle: string; } interface AlienUser { type: 'alien', codename: string } type AnyUser = HumanUser | BotUser | AlienUser; function greet(user: AnyUser): string { switch (user.type) { case 'human': return `Hello ${user.firstname} ${user.lastname}!`; case 'bot': return `0101000110 ${user.handle}`; } }

Trick #3½
Exhaustive matching (without return type)

Bonus trick
Type-level error messages

interface HumanUser { type: 'human'; firstname: string; lastname: string; } interface BotUser { type: 'bot'; handle: string; } interface AlienUser { type: 'alien', codename: string } type AnyUser = HumanUser | BotUser | AlienUser; declare function postMessage(s: string): void; function greet(user: AnyUser): void { switch (user.type) { case 'human': postMessage(`Hello ${user.firstname} ${user.lastname}!`); break; case 'bot': postMessage(`0101000110 ${user.handle}`); break; // Am I missing something? } }

TypeScript has a type which means "should never happen". It is called

never

.

Declare this function and use it in the

default

block.

function isSwitchExhaustive(a: never) {
    throw new Error('Unexpected case');
}

For type-level error messages, change function parameter to:

a: "ERROR: You are missing a case in this switch"

Why does this work?
Because unions can always be written as

A | B | ... | never

.
Never is what is left when you've removed everything from a union.

Conditional types


                        A extends B ? Yes : No;

Conditional types

type IsNumber<T> = T extends number ? 'A number' : 'Not a number'; type A = IsNumber<2>; type B = IsNumber<'hello'>;

Conditional type inference

type MyTuple = ['one', 'two']; type T = MyTuple extends [any, infer Second] ? Second : never;

We capture a type in the matching pattern, and then use it
Note that the same thing could be done with

type T = MyTuple[1]

However, this can not be done without conditional type inference:
See this definition from the standard library extracts the return type of a function.

Let's get serious!

HTTP API definition

declare function createClient<T>(api: T): { [k in keyof T]: (params?: any) => Promise<any>}; declare function createServer<T>(api: T, server: { [k in keyof T]?: (req: { params: any }) => void}); // Shared const api = { getAllCats: 'GET /api/cats', getCatByName: 'GET /api/cats/:name' }; // Client const client = createClient(api); // Server const server = createServer(api, {});

Not super TypeScript friendly...

You have a web application with a front-end and a back-end component.
You want to share the API definition between the front and back to maximize the safety of this link.
This would be a typical way to do it. A shared API definition, then helpers to create client and server implementations of that API.

But this naive approach is not safe. Take this code:

client.getCatByName({
    name: 'Olinka'
})

The parameter "name" could as well be "id" and this would compile, but fail at runtime...

For the server implementation

{
    getAllCats() {},
    getCatByName(req) {
    }
}

req.params isn't type-checked either...

Problem: There is no way to link the parameter names to their usage.

What if...

interface Endpoint<Params extends string> { params: { [k in Params]: string; }; } interface Api { [k: string]: Endpoint<any>; } type HttpClient<T extends Api> = { [k in keyof T]: (params: T[k]['params']) => void; } interface HttpRequest<T extends Endpoint<any>> { params: T['params']; } type HttpServer<T extends Api> = { [k in keyof T]?: (req: HttpRequest<T[k]>) => void; } declare function createClient<T extends Api>(def: T): HttpClient<T>; declare function createServer<T extends Api>(def: T, serv: HttpServer<T>): void; declare function GET(str: TemplateStringsArray): Endpoint<never>; declare function GET<A extends string>(str: TemplateStringsArray, a: A): Endpoint<A>; declare function GET<A extends string, B extends string>(str: TemplateStringsArray, a: A, b: B): Endpoint<A | B>; const api = { getAllCats: GET `/api/cats`, getCatByName: GET `/api/cats/${'name'}` }; const client = createClient(api); const server = createServer(api, { });

Is this... magic?

interface Endpoint<Params extends string> { params: { [k in Params]: string; } } declare function GET<A extends string>(str: TemplateStringsArray, a: A): Endpoint<A>

No, it's TypeScript! (trick #5)

GET is a template tag. You can use it like this:

const endpoint = GET `/cats/${'name'}/`

And now the string literal is captured in the type of

endpoint

!
But this doesn't work when you add a second parameter...

const endpoint = GET `/cats/${'owner'}/${'name'}/`

Hmmm...

interface Endpoint<Params extends string> { params: { [k in Params]: string; }; } declare function GET<A extends string>(str: TemplateStringsArray, a: A): Endpoint<A>; declare function GET<A extends string, B extends string>(str: TemplateStringsArray, a: A, b: B): Endpoint<A | B>; declare function GET<A extends string, B extends string, C extends string>(str: TemplateStringsArray, a: A, b: B, c: C): Endpoint<A | B | C>; declare function GET<A extends string, B extends string, C extends string, D extends string>(str: TemplateStringsArray, a: A, b: B, c: C, d: D): Endpoint<A | B | C | D>;

Problem:


                        let Flatten = [A, B, C, ...] -> A | B | C | ...

First attempt

type Flatten<T extends any[]> =

sub-problems:

"Rest" of a tuple
Recursive types

Naively, one would start with a conditional like this:

type Flatten<T extends any[]> = T extends [infer Frist, ...infer Rest] ? First | Flatten<T[Rest]> : T;

How do I get the rest of a tuple?
How do I make a recursive type?

Rest of a tuple

type Tail<T extends any[]> = ; type test = Tail<['a', 'b', 'c']>

Well known trick: Use function varargs.

type Tail<T extends any[]> = ((...args: T) => void) extends (head: any, ...tail: infer Tail) => void ? Tail : never;

Tuple utilities (trick #4)

type List<Data extends any[]> = (...tail: Data) => void; type Push<El, list extends List<any>> = list extends List<infer Data> ? (head: El, ...tail: Data) => void : never; type Pop<Head, Tail extends any[]> = (h: Head, ...tail: Tail) => void; type Tuple<L extends List<any>> = L extends List<infer T> ? T : never;

Armed with this varargs exploit, we can devise a type-level list library.
This is how you use it:

Create a list:

type MyList = List<['a', 'b', 'c']>;

Prepend an element to the list:

type MyList2 = Push<'z', MyList>;

Remove an element from the list:

type MyList3 = MyList2 extends Pop<any, infer Tail> ? Tail : never;

Get the first element:

type MyHead = MyList2 extends Pop<infer Head, any> ? Head : never;

The usage of pop is a little convoluted, but you'll see why it works like this in a minute...

Tuple flattening problems

"Rest" of a tuple
Recursive types

Recursive types

type List<DATA extends any[]> = (...tail: DATA) => void; type Push<El, list extends List<any>> = list extends List<infer Data> ? (head: El, ...tail: Data) => void : never; type Pop<Head, Tail extends any[]> = (h: Head, ...tail: Tail) => void; type Flatten<T extends List<any>> = T extends Pop<infer Head, infer Tail> ? Head | Flatten<List<Tail>> : never type A = Flatten<List<['a', 'b', 'c']>>

Split the type into two cases: edge case and general case.

type Flatten<T extends List<any>> = {
    rec: T extends Pop<infer Head, infer Tail> ? Head | Flatten<List<Tail>> : never
    end: never
};

Here only one iteration is performed. Most of the list is still uncomputed. I can access the partial result by doing:

type A = Flatten<List<['a', 'b', 'c']>>['rec']

But this needs to happen on each level of the recursion, automatically.

I can try

type Flatten = { ... }['rec']

But now the type is detected as a circular reference again!
And it makes sense: This recursion would be infinite, because I am never invoking the end case.
I need an exit condition...

type Flatten<T extends List<any>> = {
    tail: T extends Pop<infer Head, infer Tail> ? Head | Flatten<List<Tail>> : never;
    end: never;
} [
    T extends Pop<unknown, any> ? 'end' : 'tail'
];

The conditional type confuses the cycle detection algorithm!

As seen here: https://github.com/Microsoft/TypeScript/issues/14833

Trick #5: Recursive type

type List<DATA extends any[]> = (...tail: DATA) => void; type Push<El, list extends List<any>> = list extends List<infer Data> ? (head: El, ...tail: Data) => void : never; type Pop<Head, Tail extends any[]> = (h: Head, ...tail: Tail) => void; type Flatten<T extends List<any>> = { tail: T extends Pop<infer Head, infer Tail> ? Head | Flatten<List<Tail>> : never; end: never; } [ T extends Pop<unknown, any> ? 'end' : 'tail' ];

Putting it all together

interface Endpoint<Params extends string> { params: { [k in Params]: string; }; } interface Api { [k: string]: Endpoint<any>; } type HttpClient<T extends Api> = { [k in keyof T]: (params: T[k]['params']) => void; } interface HttpRequest<T extends Endpoint<any>> { params: T['params']; } type HttpServer<T extends Api> = { [k in keyof T]?: (req: HttpRequest<T[k]>) => void; } declare function createClient<T extends Api>(def: T): HttpClient<T>; declare function createServer<T extends Api>(def: T, serv: HttpServer<T>): void; type List<DATA extends any[]> = (...tail: DATA) => void; type Push<El, list extends List<any>> = list extends List<infer Data> ? (head: El, ...tail: Data) => void : never; type Pop<Head, Tail extends any[]> = (h: Head, ...tail: Tail) => void; type Flatten<T extends any[]> = FlattenRec<List<T>, 't'>['t']; interface FlattenRec<T extends List<any>, k extends 't'> { t: T extends Pop<infer Head, infer Tail> ? unknown extends Head ? never : Head | FlattenRec<List<Tail>, k>[k] : never; } declare function GET<Args extends string[]>(str: TemplateStringsArray, ...args: Args): Endpoint<Flatten<Args>>; const api = { getAllCats: GET `/api/cats`, getCatByName: GET `/api/cats/${'name'}` }; const client = createClient(api); const server = createServer(api, {});

More at https://github.com/hmil/rest.ts

TypeScript can do a lot...

But can it do everything?

What is everything?

≡

Turing came up with a theoretical machine (now dubbed the Turing machine) which could "compute stuff".
Meanwhile, Church devised a mathematical language that could also "compute stuff".

They both tried to formalize what their respective systems could compute, in vain...
Until one day, they figured that their models, as well as a third one which for some reason isn't as popupar as the two former, were equivalent.

Since then, the benchmark for how powerful a logical tool is has been "can it simulate a turing machine"? If it can, it is called "Turing complete".

It could as well have been "can it simulate lambda-calculus" and "lambda-complete" - since this is equivalent - but for some reason the version that stuck in history was the Turing one.

Is TypeScript Turing Complete?

Can it simulate a turing machine?

Can we implement lambda calculus in TypeScript?

[NSFW]

Do not try this at home work.

Variable:

var x

Abstraction:

λx. <something>

x => <something>

Application:

<something1> <something2>

<something1>(<something2>)

Lambda calculus is extremely simple. There are only 3 constructs in total:
variablesl, abstractions and applications.
A variable is like a variable in any old programing language.
An abstraction can be thought of as a function in JS
An application is what happens when you apply an expression to another expression (which hopefully evaluates to a function)

Looking at this, it's easy to see that JavaScript is turing complete. We have here a direct mapping from lambda calculus to JavaScript.
But this is not what we are looking for, we want to evaluate these expressions in the type system itself!

Example


                          (λx. x) y
                        = y


                          (λx. x x) (λy. y y)
                          (λx=(λy. y y). x x)
                        = (λy. y y) (λy. y y)

Example


                        0 = λf. λx. x
                        1 = λf. λx. f x
                        2 = λf. λx. f (f x)

                        SUCC = λn. λf. λx. f ((n f) x)

SUCC 0 = (λn. λf. λx. f ((n f) x)) 0

SUCC 0 =      λf. λx. f ((0 f) x)

SUCC 0 =      λf. λx. f (((λf. λx. x) f) x)

SUCC 0 =      λf. λx. f ((     λx. x)    x)

SUCC 0 =      λf. λx. f x

SUCC 0 = 1

Basic model


                                ZERO = λf. λx. x
                                ONE = λf. λx. f x
                                TWO = λf. λx. f (f x)

interface Variable<T extends string> { var: T; } interface Application<M, N> { m: M; n: N; } interface Abstraction<Var extends string, Expr> { v: Var; expr: Expr; }

How would we define this model as TS types? Remember, we want to only use the type system, not the runtime.

type ONE = Abstraction<'f', Abstraction<'x', Application<Variable<'f'>, Variable<'x'>>>>

This syntax is painful. Let's symplify it.

Syntactic sugar


                                ZERO = λf. λx. x
                                ONE = λf. λx. f x
                                TWO = λf. λx. f (f x)

type Variable<T extends string> = T; type Application<M, N> = [M, N]; type Abstraction<Var extends string, Expr> = (l: Var) => Expr;

type ONE = (l: 'f') => (l: 'x') => ['f', 'x']

That's better. Now let's write a machine to execute it.

Reduction step


                        (λx. ... x ...) y    ->     ... y ...

type Variable<T extends string> = T; type Application<M, N> = [M, N]; type Abstraction<Var extends string, Expr> = (l: Var) => Expr; type Reduce<T> = ; type A = (l: 'x') => (l: 'y') => 'x' type B = (l: 'z') => 'z' type test = Reduce<[A, B]>

type Reduce<T> = T extends Application<infer Left, infer Right> ?
Left extends Abstraction<infer Varname, infer Expr> ?
    Replace<Expr, Varname, Right> :
    Application<Left, Right> :
T;

type Replace<Expr, Varname, Replacement> =
Expr extends Variable<Varname> ? Replacement :
Expr extends Variable<string> ? Expr :
Expr extends Abstraction<infer AbstrVarname, infer AbstrExpr> ?
    Abstraction<AbstrVarname, Replace<AbstrExpr, Varname, Replacement>> :
Expr extends Application<infer Left, infer Right> ? 
    Application<Replace<Left, Varname, Replacement>, Replace<Right, Varname, Replacement>> :
Expr

We need to make this expression recursive. But this time I don't want to re-write the end condition like we did before, because this expression is complex.
There's an other, even more ridiculous, trick you can use here...

interface Replace<Expr, Varname, Replacement, t extends 't'> {
    t: ... same expression as above. 
           Substitute `Replace<...>` with `Replace<..., t>[t]`
}

---
Show reduction of test expr
---
Note shadowing special case:

type A = (l: 'x') => ['x', (l: 'x') => 'x']

Varname extends AbstrVarname ? Expr : Abstraction<...

Show that expression is not fully reduced. Need to write in another Reduce.
We'll address this problem later.
---
Try to reduce SUCC ZERO. Do not explain what 0, 1 and SUCC, mean. Just that SUCC 0 should equal 1.

type _0 = (l: 'f') => (l: 'x') => 'x'
type _1 = (l: 'f') => (l: 'x') => ['f', 'x']
type SUCC = (l: 'n') => (l: 'f') => (l: 'x') => ['f',[['n','f'],'x']]

type SUCC_0 = Reduce<[SUCC, _0]>

SHOW THAT inner expression is not reduced.
Wrapping in more Reduce does not help.
Add this to Reduce:

T extends Abstraction<infer Varname, infer Expr> ?
                                Abstraction<Varname, Reduce<Expr>> :

Apply recursive trick again.
SHOW THAT lambda expr is not fully reduced. Wrapp in a couple more reduce, then it is fully reduced.

---

type ReduceAll<T> = true extends CanReduce<T> ? ReduceAll<Reduce<T>> : T;

type CanReduce<T> = T extends Reduce<T> ? false : true;

Let's have fun

Church numerals (integers)

Boolean logic

// Note: This version is slightly optimized in order to hit the recursion limit a bit later type Variable<T extends string> = T; type Application<M, N> = [M, N]; type Abstraction<Var extends string, Expr> = (l: Var) => Expr; type Replace<Expr, Varname, Replacement> = ReplaceRec<Expr, Varname, Replacement, 't'>['t']; interface ReplaceRec<Expr, Varname, Replacement, t extends 't'> { t: Expr extends Variable<infer VarVarname> ? VarVarname extends Varname ? Replacement : Expr : Expr extends Abstraction<infer AbstrVarname, infer AbstrExpr> ? AbstrVarname extends Varname ? Expr : Abstraction<AbstrVarname, ReplaceRec<AbstrExpr, Varname, Replacement, t>[t]> : Expr extends Application<infer Left, infer Right> ? Application<ReplaceRec<Left, Varname, Replacement, t>[t], ReplaceRec<Right, Varname, Replacement, t>[t]> : Expr; } type Reduce<T> = ReduceRec<T, 't'>['t']; interface ReduceRec<T, k extends 't'> { t: T extends Application<infer Left, infer Right> ? Left extends Abstraction<infer Varname, infer Expr> ? Replace<ReduceRec<Expr, k>[k], Varname, ReduceRec<Right, k>[k]> : Application<ReduceRec<Left, k>[k], ReduceRec<Right, k>[k]> : T extends Abstraction<infer Varname, infer Expr> ? Abstraction<Varname, ReduceRec<Expr, k>[k]> : T ; } // Note: The naive implementation of CanReduce hits the recursion limit too fast. // We use this more sofisticated version instead. type CanReduce<T> = CanReduceRec<T, 't'>['t']; interface CanReduceRec<T, k extends 't'> { t: T extends Application<Abstraction<any, any>, any> ? true : T extends Application<infer M, infer N> ? CanReduceRec<M, 't'>[k] | CanReduceRec<N, 't'>[k] : T extends Abstraction<any, infer expr> ? CanReduceRec<expr, 't'>[k] : never; } type ReduceAll<T> = ReduceAllRec<T, 't'>['t']; interface ReduceAllRec<T, k extends 't'> { t: true extends CanReduce<T> ? ReduceAllRec<Reduce<T>, k>[k] : T; } type _0 = (l: 'f') => (l: 'x') => 'x'; type _1 = (l: 'f') => (l: 'x') => ['f', 'x'] type SUCC = (l: 'n') => (l: 'f') => (l: 'x') => ['f',[['n','f'],'x']]; type SUCC_0 = ReduceAll<[SUCC, _0]>;

type _0 = (l: 'f') => (l: 'x') => 'x';
type _1 = (l: 'f') => (l: 'x') => ['f', 'x']
type SUCC = (l: 'n') => (l: 'f') => (l: 'x') => ['f',[['n','f'],'x']];

type _2 = ReduceAll<[SUCC, _1]>;
type _3 = ReduceAll<[SUCC, _2]>;

type Plus = (l: 'm') => (l: 'n') => (l: 'f') => (l: 'x') => [['m', 'f'],[['n', 'f'],'x']];
type _5 = ReduceAll<[[Plus, _2], _3]>;

Booleans:

type True = (l: 'x') => (l: 'y') => 'x';
type False = (l: 'x') => (l: 'y') => 'y';

type And = (l: 'p') => (l: 'q') => [['p','q'],'p'];
type Or = (l: 'p') => (l: 'q') => [['p','p'],'q'];
type Not = (l: 'p') => [['p',False],True];

type LogicTest = ReduceAll<[[Or, [[And, False], True]], False]>;

type IsZero = (l: 'n') => [['n', (l: 'x') =>  False], True];
type Is0Zero = ReduceAll<[[[IsZero, _0], 'is zero'], 'not zero']>;
type Is1Zero = ReduceAll<[[[IsZero, _1], 'is zero'], 'not zero']>;

We've implmented lambda-calculus in TypeScript

Therefore, TypeScript is Turing-Complete.

The end.

or is it?

// Note: This version is slightly optimized in order to hit the recursion limit a bit later type Variable<T extends string> = T; type Application<M, N> = [M, N]; type Abstraction<Var extends string, Expr> = (l: Var) => Expr; type Replace<Expr, Varname, Replacement> = ReplaceRec<Expr, Varname, Replacement, 't'>['t']; interface ReplaceRec<Expr, Varname, Replacement, t extends 't'> { t: Expr extends Variable<infer VarVarname> ? VarVarname extends Varname ? Replacement : Expr : Expr extends Abstraction<infer AbstrVarname, infer AbstrExpr> ? AbstrVarname extends Varname ? Expr : Abstraction<AbstrVarname, ReplaceRec<AbstrExpr, Varname, Replacement, t>[t]> : Expr extends Application<infer Left, infer Right> ? Application<ReplaceRec<Left, Varname, Replacement, t>[t], ReplaceRec<Right, Varname, Replacement, t>[t]> : Expr; } type Reduce<T> = ReduceRec<T, 't'>['t']; interface ReduceRec<T, k extends 't'> { t: T extends Application<infer Left, infer Right> ? Left extends Abstraction<infer Varname, infer Expr> ? Replace<ReduceRec<Expr, k>[k], Varname, ReduceRec<Right, k>[k]> : Application<ReduceRec<Left, k>[k], ReduceRec<Right, k>[k]> : T extends Abstraction<infer Varname, infer Expr> ? Abstraction<Varname, ReduceRec<Expr, k>[k]> : T ; } // Note: The naive implementation of CanReduce hits the recursion limit too fast. // We use this more sofisticated version instead. type CanReduce<T> = CanReduceRec<T, 't'>['t']; interface CanReduceRec<T, k extends 't'> { t: T extends Application<Abstraction<any, any>, any> ? true : T extends Application<infer M, infer N> ? CanReduceRec<M, 't'>[k] | CanReduceRec<N, 't'>[k] : T extends Abstraction<any, infer expr> ? CanReduceRec<expr, 't'>[k] : never; } type ReduceAll<T> = ReduceAllRec<T, 't'>['t']; interface ReduceAllRec<T, k extends 't'> { t: true extends CanReduce<T> ? ReduceAllRec<Reduce<T>, k>[k] : T; } type _4 = (l: 'f') => (l: 'x') => ['f', ['f', ['f', ['f', 'x']]]]; type Mult = (l: 'm') => (l: 'n') => (l: 'f') => ['m', ['n', 'f']]; type _16 = ReduceAll<[[Mult, _4], _4]>;

The end

Stay in touch

🌍 blog.hmil.fr

hmil

HadrienMilano

Thanks:

B-roll

Raw clips that didn't make it to the presentation.

Conditional type inference distributivity

type Strings = 'a' | 'b' | 'c'; type Test<T> = T extends 'b' ? 'YES' : 'NO';

Decorators


                        @(some expression which evalutates to a function)

class decorator


                        function MyDecorator(t: any) {
                        }

                        @MyDecorator
                        class MyClass {

                        }


                        function MyDecorator() {
                            return function(t: any) { }
                        }

                        @MyDecorator()
                        class MyClass {

                        }

class decorator

...or


                        function MyDecoratorOverkillFactory() {
                            return {
                                d: () => {
                                    return function(t: any) { };
                                }
                            };
                        }

                        @MyDecoratorOverkillFactory().d()
                        class MyClass {

                        }

Tip: Restrict the scope of your decorator

abstract class AModel { id: string; } function Model(m: typeof AModel) { } @Model class MyModel extends AModel { }

Member decorator

abstract class AModel { id: string; } function MyDecorator(t: unknown, p: PropertyKey) { } class MyClass extends AModel { @MyDecorator id: string; }

Better yet:

function MyDecorator<T extends AModel>(model: T, key: keyof T) {

}

Now, the decorator can only be applied to members of a class extending AModel.

Decorators can't change the type of the object they decorate...

...but they can verify it!

example:
Modelling library

Trick #xxx: Class constraint enforcement from decorator via type-level programing.

function ModelProperty<T>(model: T, key: keyof T) { } class MyModel { @ModelProperty id: string; }

This library lets you declare models for serialization/deserialization (eg. db, network, domain...) What if we want all members to be declared optional?

ModelProperty<T, K extends keyof T>(model: VerifyModel<T, K>, key: K
type VerifyModel<T, K extends keyof T> = undefined extends T[K] ? T : never;

Can we make the error message more friendly?
Replace never with this type:

type ERR_NOT_OPTIONAL = "Error: Model properties must be optional

What if we want to add a default?

type DefaultProvider<T> = {
default: () => T;
}

type ModelPropertyParams = Partial<DefaultProvider<any>>;

TDefaults extends DefaultProvider<infer DefaultType> ? T : ERR_NOT_OPTIONAL;

We can also check the type of the default value...

DefaultType extends T[K] ? T : ERR_BAD_TYPE

But if I specify a bad default type to an optional member...
Let's refactor a bit first

type VerifyDefaultType<T, TDefaults, ExpectedType, Else> = 
TDefaults extends DefaultProvider<infer DefaultType> ?
DefaultType extends ExpectedType ? T : ERR_BAD_TYPE
: Else;

Trick #3
Type guards

interface HumanUser { type: 'human'; firstname: string; lastname: string; } interface BotUser { type: 'bot'; handle: string; } interface AlienUser { type: 'alien', codename: string } type AnyUser = HumanUser | BotUser | AlienUser; function isHuman(t: AnyUser): t is HumanUser { return t.type === 'human'; } function greet(user: AnyUser): string { }

                        if (isHuman(user)) {
                            return user.firstname;
                        }
                        return `This is not a human: ${user.type}`;