Types of property 'value' are incompatible / ts(2322)

In short I have a type FieldHeader

interface Item {
  id: string;
}

interface BaseFieldHeader<
  item extends Item,
  value extends boolean | number | string
> {
  get: (item: item) => value;
}

type FieldHeader<item extends Item> =
  | (BaseFieldHeader<item, boolean> & {
    type: 'boolean';
  })
  | (BaseFieldHeader<item, number> & {
    type: 'number';
  })
  | (BaseFieldHeader<item, string> & {
    type: 'string';
  });

that is used to create Fields by evaluating get with an Item:

interface BaseField<value extends boolean | number | string> {
  key: string;
  value: value;
}

type Field =
  | (BaseField<boolean> & {
    type: 'boolean';
  })
  | (BaseField<number> & {
    type: 'number';
  })
  | (BaseField<string> & {
    type: 'string';
  });

type will always match the return type of get / the type of value resp.

Thus, setting

type TableHeader<item extends Item> = Record<
  string,
  FieldHeader<item>
>;

and—given an Item User—creating fields from a TableHeader like so

interface User extends Item {
  age: number;
}

const tableHeader: TableHeader<User> = {
  age: {
    get: (user) => user.age,
    type: "number"
  }
}

const user: User = {
  id: "frank",
  age: 34
}

const tableRow: Field[] = Object.entries(tableHeader).map(
  ([key, field]) =>
  ({
    key,
    value: field.get(user),
    type: field.type,
  }
  )
)

why do I get the error

Type '{ key: string; value: string | number | boolean; type: "string" | "number" | "boolean"; }[]' is not assignable to type 'Field[]'.
  Type '{ key: string; value: string | number | boolean; type: "string" | "number" | "boolean"; }' is not assignable to type 'Field'.
    Type '{ key: string; value: string | number | boolean; type: "string" | "number" | "boolean"; }' is not assignable to type 'BaseField<string> & { type: "string"; }'.
      Type '{ key: string; value: string | number | boolean; type: "string" | "number" | "boolean"; }' is not assignable to type 'BaseField<string>'.
        Types of property 'value' are incompatible.
          Type 'string | number | boolean' is not assignable to type 'string'.
            Type 'number' is not assignable to type 'string'.(2322)

? Playground

The problem TypeScript is having with your code is that it cannot analyze the type of single value { key, value: field.get(user), type: field.type } multiple times. It does so all at once, and therefore value is of the union type string | number | boolean and type is of the union type "string" | "number" | "boolean", and any correlation between them has been lost. TypeScript therefore cannot directly support "correlated union types", as described in microsoft/TypeScript#30581.

If the compiler could analyze that value once for each possible union member of the type of field, then it would see that each member works separately and thus works overall. But if the compiler did this whenever it encountered a value of a union type, it would be catastrophically damaging to performance. So that's not possible. You could manually lead the compiler through analysis by using a switch statement or series of if/else clauses, but then you'd be writing the same value multiple times.

The easiest approach is just to use a type assertion because you're smarter than the compiler:

const tableRow: Field[] = Object.entries(tableHeader).map(
  ([key, field]) => ({
    key,
    value: field.get(user),
    type: field.type,
  } as Field)
);

but then it's your job to make sure you did it right, not the compiler's. You've taken over type safety verification from the compiler.

There is a recommended approach to dealing with correlated unions in a way that the compiler can follow. It's described in microsoft/TypeScript#47109 and involves refactoring to use generics instead of unions. Generics are the only really supported way of getting the compiler to analyze "multiple cases at once".

In particular you want to represent the operations in terms of some basic key-value interface and mapped types over that interface, as well as generic indexes into such types.

For your code example it might look like this. The basic key-value interface is:

interface TypeMap {
  boolean: boolean;
  number: number;
  string: string;
}

which represents the relationship between the type property and the corresponding data type. Then we can rewrite your FieldHeader and TableFieldHeader types in terms of it as follows:

type FieldHeader<I extends Item, K extends keyof TypeMap = keyof TypeMap> =
  { [P in K]: {
    type: P,
    get: (item: I) => TypeMap[P]
  } }[K]

type Field<K extends keyof TypeMap = keyof TypeMap> =
  { [P in K]: {
    type: P,
    key: string;
    value: TypeMap[P]
  } }[K]

These are both distributive object types that evaluate to unions by immediately indexing into mapped types. They are also written to be generic so that, say, Field<"string"> is just the string-related member of the union. Similarly TableHeader is expanded to be generic that way:

type TableHeader<I extends Item, K extends keyof TypeMap = keyof TypeMap> =
  Record<string, FieldHeader<I, K>>;

And now we can write the code to convert an item/table-header pair into an array of fields. This needs to be generic in K extends keyof TypeMap in order for the compiler to understand that this works, so we have to make a generic function. This could be an anonymous function expression but it's probably clearer to give it a name:

function mapTableHeaderToFieldArray<I extends Item, K extends keyof TypeMap>(
  item: I, tableHeader: TableHeader<I, K>): Field<K>[] {
  return Object.entries(tableHeader).map(([key, field]) => ({
    key,
    type: field.type,
    value: field.get(item)
  }))
}

That compiles without error. And now we can finally use it:

const user: User = {
  id: "frank",
  age: 34
}

const tableRow: Field[] =
  mapTableHeaderToFieldArray(user, tableHeader);

Hooray, it works!

In the above refactoring everything now compiles without error, and it is as close as we can get to having the compiler verify type safety for us. But is it worth it? That depends strongly on your use cases. If you really want the compiler to complain if you make a mistake and you don't want to write out a bunch of manual cases, then it might be worth it. But if you value idiomatic code and developer productivity more than you value compiler-verified type safety, then you should probably just use a type assertion and move on; it's not wrong to do so, as long as you're aware of the options and have assessed their relative applicability to your needs.

Playground link to code