What is preventing the TypeScript compiler from accepting this code that appears to be valid?

Question

What is preventing the TypeScript compiler from accepting this code that appears to be valid?

I am encountering difficulties comprehending why the TypeScript type-checker is denying code that appears to be valid.

export type Fn<I, O> = (value: I) => O
type FInput<F extends Fn<any, any>> = F extends Fn<infer I, any> ? I : never
type FOutput<F extends Fn<any, any>> = F extends Fn<any, infer O> ? O : never

type FnMap = {
  numToInt: Fn<number, number>
  numToStr: Fn<number, string>
  strToNum: Fn<string, number>
  strToStr: Fn<string, string>
}

const fnMap: FnMap = {
  numToInt: (x) => Number(x.toFixed(0)),
  numToStr: (x) => x.toString(10),
  strToNum: (x) => parseInt(x),
  strToStr: (x) => x.toUpperCase(),
} as const

function doWork<T extends keyof FnMap>(key: T, input: FInput<FnMap[T]>): FOutput<FnMap[T]> {
  const fn = fnMap[key]

  return fn(input)
  // Type 'string | number' is not assignable to type 'FOutput<FnMap[T]>'.
  //   Type 'string' is not assignable to type 'FOutput<FnMap[T]>'.
  // Argument of type 'string | number' is not assignable to parameter of type 'never'.
  //   Type 'string' is not assignable to type 'never'.
}

In the provided example, TypeScript correctly auto-completes the doWork function (you can experiment with it on the playground).

Is there a particular reason for this failure? Is there another way to express this?

typescript typescript-generics

Answer 1

Answer №1

The reason your code isn't working is due to the compiler's struggle in evaluating conditional types that depend on generic type parameters. When invoking a function of type FnMap[T] within doWork(), and passing an argument of type FInput<FnMap[T]>, the compiler fails to connect this with FOutput<FnMap[T]>. This confusion arises because FInput and FOutput are conditional types, while T is generic, leading to ambiguity for the compiler. Consequently, it widens T to its constraint but faces uncertainties about input suitability and output correctness.

To resolve this issue, refactoring is recommended to explicitly represent things in terms of indexed accesses on mapped types as discussed here. By defining functions like (arg: XXX) => YYY for specific XXX and YYY, the compiler can deduce direct relationships between inputs and outputs more effectively. While these changes may seem minor from a human perspective compared to the original version, they significantly improve compiler understanding.

To demonstrate with your sample code, begin by defining the mapping object and deriving types:

// Mapping Object
const _fnMap = {
  numToInt: (x: number) => Number(x.toFixed(0)),
  numToStr: (x: number) => x.toString(10),
  strToNum: (x: string) => parseInt(x),
  strToStr: (x: string) => x.toUpperCase(),
}
type _FnMap = typeof _fnMap;

// Mapped Types
type FnMapArgs = { [K in keyof _FnMap]: Parameters<_FnMap[K]>[0] };
type FnMapRets = { [K in keyof _FnMap]: ReturnType<_FnMap[K]> }
type FnMap = { [K in keyof _FnMap]: (input: FnMapArgs[K]) => FnMapRets[K] };

// Assigning Equivalent Types
const fnMap: FnMap = _fnMap;

With non-generic specific types defined, the compiler can now process them effectively. By specifically defining indexes through mapped types, we update doWork() as follows:

function doWork<K extends keyof _FnMap>(type: K, input: FnMapArgs[K]): FnMapRets[K] {
  return fnMap[type](input); // No errors arise
}

Within this function, fnMap[type] is interpreted by the compiler as FnMap[K], enabling seamless interaction based on assigned mappings. As a result, the function generates an output of type FnMapRets[K].

For further exploration, refer to the https://www.typescriptlang.org/play?#code/HYQwtgpgzgDiDGEAEApeIA2AvJBvAsAFBFJKiSwLIAKATgPYBGGEYeJpSEAHjPbQBckAgJ4...ongoURL.

Answer 2

The reason your code isn't working is due to the compiler's struggle in evaluating conditional types that depend on generic type parameters. When invoking a function of type FnMap[T] within doWork(), and passing an argument of type FInput<FnMap[T]>, the compiler fails to connect this with FOutput<FnMap[T]>. This confusion arises because FInput and FOutput are conditional types, while T is generic, leading to ambiguity for the compiler. Consequently, it widens T to its constraint but faces uncertainties about input suitability and output correctness.

To resolve this issue, refactoring is recommended to explicitly represent things in terms of indexed accesses on mapped types as discussed here. By defining functions like (arg: XXX) => YYY for specific XXX and YYY, the compiler can deduce direct relationships between inputs and outputs more effectively. While these changes may seem minor from a human perspective compared to the original version, they significantly improve compiler understanding.

To demonstrate with your sample code, begin by defining the mapping object and deriving types:

// Mapping Object
const _fnMap = {
  numToInt: (x: number) => Number(x.toFixed(0)),
  numToStr: (x: number) => x.toString(10),
  strToNum: (x: string) => parseInt(x),
  strToStr: (x: string) => x.toUpperCase(),
}
type _FnMap = typeof _fnMap;

// Mapped Types
type FnMapArgs = { [K in keyof _FnMap]: Parameters<_FnMap[K]>[0] };
type FnMapRets = { [K in keyof _FnMap]: ReturnType<_FnMap[K]> }
type FnMap = { [K in keyof _FnMap]: (input: FnMapArgs[K]) => FnMapRets[K] };

// Assigning Equivalent Types
const fnMap: FnMap = _fnMap;

With non-generic specific types defined, the compiler can now process them effectively. By specifically defining indexes through mapped types, we update doWork() as follows:

function doWork<K extends keyof _FnMap>(type: K, input: FnMapArgs[K]): FnMapRets[K] {
  return fnMap[type](input); // No errors arise
}

Within this function, fnMap[type] is interpreted by the compiler as FnMap[K], enabling seamless interaction based on assigned mappings. As a result, the function generates an output of type FnMapRets[K].

For further exploration, refer to the https://www.typescriptlang.org/play?#code/HYQwtgpgzgDiDGEAEApeIA2AvJBvAsAFBFJKiSwLIAKATgPYBGGEYeJpSEAHjPbQBckAgJ4...ongoURL.

What is preventing the TypeScript compiler from accepting this code that appears to be valid?

Answer №1

Similar questions

Is there a way to define a return type conditionally depending on an input parameter in typing?

Include module A in module B, even though module A has already included module B's Angular

Having trouble with the .d.ts module for images?

Can a mandatory attribute be made non-essential within an intersection category?

Updating the state of a nested array using React Hooks

Tweaking the column name and data values within a mat table

Automatically injecting dependencies in Aurelia using Typescript

Setting IDPs to an "enabled" state programmatically with AWS CDK is a powerful feature that allows for seamless management of

Creating a JSON formatted post request with Angular 4 and Rails 5

Determining the parameter type of an overloaded callback: A comprehensive guide

Determine the point where a cube intersects a plane using Three.js

Use the Express application as an argument for the http.createServer function

Unwrapping nested objects in a JSON array with JavaScript: A step-by-step guide

Can anyone clarify what the term 'this' is referring to in this particular snippet of code?

Guide to leveraging tanstack table v8 for sorting data within a specific date range

Unable to locate TypeScript's before() and after() methods

Removing the semicolon from the end of a string in JavaScript

Tips for modifying the JSON format within a Spring and Angular project

Ways to display only a specific color in an image

Angular 11 is causing confusion by incorrectly applying the Http interceptor to sibling modules