Comments: Conditional types in TypeScript

[ds300]

http://artsy.github.io/blog/2018/11/21/conditional-types-in-typescript/

[johnnyreilly]

Hands down the best thing I've read on conditional types. Well done! The TypeScript should make this part of their official docs! ♥️🌻

cc @DanielRosenwasser
http://artsy.github.io/blog/2018/11/21/conditional-types-in-typescript/

[theutz]

I have been struggling with understanding this topic almost every day for months. This is the first thing I've read in plain speech—where I could really understand it. Your writing is excellent, entertaining, and informative.

This should absolutely be a part of the TypeScript documentation. Thank you!

[ds300]

Thanks for the kind words, peeps 😊 I'm super glad you've found it helpful! 💃

[j1r1k]

@ds300 How would you implement a body of process function?

export function process<T extends string | null>(text: T): T extends string ? string : null {
  return text === null ? null : text
}

fails with

[ts]
Type 'T | null' is not assignable to type 'T extends string ? string : null'.
  Type 'null' is not assignable to type 'T extends string ? string : null'. [2322]

[ds300]

Ah yeah! That's an open issue microsoft/TypeScript#24929 — I left this out of my talk but should probably have included it in the blog post as another caveat.

Unfortunately the only workaround right now is to cast your return values as any. So usages of the function will still get the benefit of the conditional type, but you can't get TypeScript to check that your function implementation is entirely type safe.

[bdurrani]

With your first code snippet, I get the following error

error TS2322: Type 'string' is not assignable to type 'T extends string ? string : null'.

This is the link to the playground.

I'm probably missing something simple. Any ideas? Did something change recently? I'm using TS 3.2.2
Thanks

[ds300]

Hey @bdurrani! 👋

You're right. That's an open issue: TS can't type-check the return value of functions with conditional return types defined in terms of type parameters. See the link in the comment above yours for more info ☝️

[bdurrani]

Hey @bdurrani! 👋

You're right. That's an open issue: TS can't type-check the return value of functions with conditional return types defined in terms of type parameters. See the link in the comment above yours for more info ☝️

I should have look at that. Thanks for responding. great article.

[Daniel15]

This is such a fantastic post. Thank you so much for writing it!

[schmod]

Thanks for the fantastic post!

I'm wondering if this is similar to @bdurrani's issue, but I'm having trouble finding a way to write a typesafe implementation of a dispatch function that takes advantage of type-narrowing of the args parameter:

function dispatch<T extends ActionType>(
  type: T,
  args: ExtractActionParameters<Action, T>
): void {
  if (type === 'LOG_IN') {
    console.log(args.emailAddress) // error
  }
}

Inside of the if statement, TS hasn't actually narrowed the definition of args, and has instead left it as the union of all possible values of args.

---

The best thing I've come up with so far is this (fairly ugly) type-guard:

function isType<T extends ActionType>(
  desired: T,
  actual: ActionType,
  args: ExcludeTypeField<Action>
): args is ExtractActionParameters<Action, T> {
  return desired === actual;
}

function dispatch<T extends ActionType>(
  type: T,
  args: ExtractActionParameters<Action, T>
): void {
  if (isType("LOG_IN", type, args)) {
    console.log(args.emailAddress); // 👍
  }
}

Have others run into this, and come up with a way to make the TypeScript compiler be a little more intuitive without resorting to type-guards or unsafe casts?

[ds300]

I suppose the problem is that TypeScript can't yet narrow the types of two independent variables, even if their types are codependent.

One thing I might be tempted to try would be combining the values back into a single Action object.

function dispatch<T extends ActionType>(
    type: T,
    args: ExtractActionParameters<Action, T>
): void {
    const action = {type, ...args} as Action
    switch (action.type) {
        case "LOG_IN":
            action.emailAddress // 👍
            break;
    }
}

Obviously not ideal if you need to run dispatch in a tight loop.

[hienqnguyen]

Thank you for the post. It is extremely helpful. Could you please advise how I can address the issue below?

const myFunc = [
  { func: (s: string): number => parseInt(s) },
  { func: (n: number): boolean => n === 17 }
];

type FuncType = (typeof myFunc extends Array<(infer A)> ? A : never)["func"];
type ExtractInput<T> = T extends (i: infer I) => any ? I: never;
type ArgsType = ExtractInput<FuncType>;

const executeFunc = (f: FuncType, input: ArgsType) => f(input);

compiier doesn't like f(input), it says Argument of type 'string | number' is not assignable to parameter of type 'string & number.

See it Playground

[ds300]

@hienqnguyen Yeah I see what's going on there. That's the correct behaviour. Let me break it down:

FuncType ends up being a union of the two function signatures in myFunc. i.e.

type FuncType = ((s: string) => number) | ((n: number) => boolean)

So when you ExtractInput on it the the union gets distributed over

type ArgsType = ExtractInput<(s: string) => number> | ExtractInput<(n: number) => boolean>

and so

type ArgsType = string | number

But if you try to call FuncType you can't pass a string | number because there's a 50/50 chance that there's a type error. If you pass a string then the function that expects a number will fail. If you pass a number than the function that expects a string will fail. We don't know which function will be called so the only safe thing to pass is something which is both a string and a number, i.e. string & number, so that's what TypeScript asks for.

I think a way to fix this would be to avoid making ExtractInput a distributive conditional type.

A hacky way to do that which just popped into my head would be to wrap both sides of the extends clause with some arbitrary type wrapper. e.g. Array

type ExtractInput<T> = Array<T> extends Array<(i: infer I) => any> ? I: never;

You could do it with a tuple for fewer characters, but even more confusing to read IMO (definitely add a comment if you decide to use either of these 😅)

type ExtractInput<T> = [T] extends [(i: infer I) => any] ? I: never;

Check it out in the playground

[marzelin]

TypeScript won't let us pass something that is of type string | null because it's not smart enough to collapse the overloaded signatures when that's possible. So we can either add yet another overload signature for the string | null case, or we can be like (╯°□°)╯︵ ┻━┻ and switch to using conditional types.

function process<T extends string | null>(
text: T
): T extends string ? string : null {
...
}

No, we cannot use conditional types here since the signature is invalid. It's not a bug, it's a design limitation so it will probably never work.

class A {}
class B {}
const b: B = new A() // ✔ all good
const a: A = new B() // ✔ all good
new A() instanceof B // => false

TypeScript is happy treating two completely unrelated classes as equivalent because they have the same structure and the same capabilities. Meanwhile, when checking the types at runtime, we discover that they are actually not equivalent.

types and classes are different things: a type refers to interface and a class refers to implementation. instanceof doesn't check types.

interface Shape {
color: string
}
class Circle {
color: string
radius: number
}
// ✔ All good! Circles have a color
const shape: Shape = new Circle()
// ✘ Type error! Not all shapes have a radius!
const circle: Circle = shape

Speaking structurally we can say that A extends B is a lot like 'A is a superset of B', or, to be more verbose, 'A has all of B's properties, and maybe some more'.

A extends B is a lot like 'A is a subset of B'
Circle is a subset of Shape.
A type or set is super if it contains more elements (or at least it has all elements from the other set). It's all about quantity not quality. Superman isn't a superset of Man even though he's much more powerful than a normal man. Supertype is always more basic and subtype more sophisticated or specific.