Typescript Issue on Discriminated Union – Telegram API

Let me paraphrase what you’re trying to do and the problem you’re running into. You have a discriminated union:

interface Foo {
    type: "foo",
    fooMeta: { a: string }
}

interface Bar {
    type: "bar",
    barMeta: { b: number }
}

type Types = Foo | Bar;

And you have some functions that map each member of this union to some corresponding output type:

declare function doFoo(data: Foo): number;
declare function doBar(data: Bar): Date;

You’d like to package these into a single generic function that accepts any member of the discriminated union and delegates to the corresponding function, and returns the corresponding function’s return type:

type ReturnLookup = {
    "foo": number;
    "bar": Date;
};    

declare function create<T extends Types>(data: T): ReturnLookup[T['type']];

const doneFoo = create({ type: "foo", fooMeta: { a: "" } }); // number
const doneBar = create({ type: "bar", barMeta: { b: 123 } }); // Date

But, unfortunately, you can’t seem to implement this function without getting type errors:

export function create<T extends Types>(data: T): ReturnLookup[T['type']] {
    if (data.type === 'foo') {
        return doFoo(data) // number is not assignable to number & Date
    }
    return doBar(data) // Date is not assignable to number & Date
}

Why is this happening and how can you fix it?

This is happening because the compiler cannot narrow the type parameter T when you check the value data of type T. Checking data.type narrows data, but it does not affect T itself. Since T is not affected inside the function implementation, the compiler never knows whether you should return the return type of doFoo or the return type of doBar. The only thing it would see as safe is if you somehow returned a value of both types, that is, the intersection of both types. And that’s why you get errors about number or Date not being assignable to the intersection number & Date.

There are various issues in GitHub that mention this problem and request ways to fix it. One is microsoft/TypeScript#33014, where it is suggested that there be some way to narrow the generic type parameter T.

Another is microsoft/TypeScript#30581, which deals with correlated union types, and the recommended fix for this issue at microsoft/TypeScript#47109 gives a way forward here, if you’re willing to refactor:

The refactoring is to change your discriminated union to an object type whose keys are the discriminant property and whose property values are the rest of the members:

interface TypeMapping {
    foo: {
        fooMeta: { a: string }
    },
    bar: {
        barMeta: { b: number }
    }
}

Then, instead of defining Types as a union, you define it as a distributive object type where you make a mapped type and immediately index into it to get a union:

type Types<K extends keyof TypeMapping = keyof TypeMapping> =
    { [P in K]: { type: P } & TypeMapping[P] }[K]

type Foo = Types<"foo">
type Bar = Types<"bar">

The types Foo, Bar, and Types types are equivalent to the ones at the top (note that Types without the generic argument evaluates to Types<keyof TypeMapping> due to the default), but now the compiler explicitly sees the relationship between Types<K> and the union members of K.

Then we can package the doFoo and doBar functions into a single object whose type is also explicitly represented in terms of the keys of TypeMapping:

const funcs: { [P in keyof TypeMapping]: (data: Types<P>) => ReturnLookup[P] } = {
    foo: doFoo,
    bar: doBar
}

And this representation is important. It allows the compiler to understand that, for a value data of type Types<K> for generic K, you can call funcs[data.type](data) and get the output type ReturnLookup[K]:

export function create<K extends keyof TypeMapping>(
    data: Types<K>
): ReturnLookup[K] {
    return funcs[data.type](data); // okay
}

const doneFoo = create({ type: "foo", fooMeta: { a: "" } }); // number
const doneBar = create({ type: "bar", barMeta: { b: 123 } }); // Date

So there’s no error there, hooray!

But take note, the reason this works has very much to do with the exact representation of the types here. If, for example, you remove the annotation of funcs above:

const funcs = {
    foo: doFoo,
    bar: doBar
}

Then the error comes back:

return funcs[data.type](data); // error, number | Date not number & Date

That’s because the compiler loses the connection between the type of funcs[data.type] and that of data (which is the whole topic of microsoft/TypeScript#30581), and you might as well not have refactored at all.

So be careful with this technique!

Playground link to code