Is it possible for a conditional type to dictate the type it is connected

Question

Is it possible for a conditional type to dictate the type it is connected

I'm currently attempting to utilize conditional types with generics in order to determine another type, but I am facing issues with the narrowing of the conditional type. Specifically, I am looking to narrow down the conditional type based on the parameter's type.

export function foo<T extends "a" | "b">(parameter: T) {
    type Foo = T extends "a" ? 1 : 2;
    let foo: Foo;
    if (parameter === "a") foo = 1;
    else foo = 2;
}

I believe this issue is similar to the one discussed in Conditional type is not being narrowed by if/else..., although I am unsure of the exact cause.

Are there any best practices for situations like these where I need to determine a type based on the parameter's type?

P.S. I prefer not to use Discriminated Unions as it would require adding parameters like seen below.

type A = { type: "a"; foo?: 1 };
type B = { type: "b"; foo?: 2 };
export function foo<T extends A | B>(parameter: T) {
  // The parameter is not strict. (foo can be one of parameter)
  if (parameter.type === "a") parameter.foo = 1;
  else parameter.foo = 2;
}

The above details outline my final attempt at solving this issue. I have searched through various resources, but have yet to find an explanation regarding this specific problem.

typescript

Answer 1

Answer №1

Narrowing focuses on the values, not the types: therefore, once foo is declared, any change in the type of parameter will not and should not affect foo retroactively.

One approach to make your code function without using discriminated unions or similar techniques is by defining foo within the guarded blocks that narrow down the parameter:

type Param = "a" | "b";

type Foo<P extends Param> =
  P extends "a" ? 1 :
  P extends "b" ? 2 : never;

export function test_foo(p: Param) {
  p;  // (parameter) p: Param

  // this would *not* be narrowed!
  let foo: Foo<typeof p>;  // let foo: 1 | 2

  if (p === "a") {
    p;  // (parameter) p: "a"

    // this *does* get narrowed!
    let foo: Foo<typeof p>;  // let foo: 1

    foo = 1;
    //foo = 2;  // ERROR: Type '2' is not assignable to type '1'.
  }
  else {
    p;  // (parameter) p: "b"

    // this *does* get narrowed!
    let foo: Foo<typeof p>;  // let foo: 2

    //foo = 1;  // ERROR: Type '1' is not assignable to type '2'.
    foo = 2;
  }
}

Link to playground

Answer 2

Narrowing focuses on the values, not the types: therefore, once foo is declared, any change in the type of parameter will not and should not affect foo retroactively.

One approach to make your code function without using discriminated unions or similar techniques is by defining foo within the guarded blocks that narrow down the parameter:

type Param = "a" | "b";

type Foo<P extends Param> =
  P extends "a" ? 1 :
  P extends "b" ? 2 : never;

export function test_foo(p: Param) {
  p;  // (parameter) p: Param

  // this would *not* be narrowed!
  let foo: Foo<typeof p>;  // let foo: 1 | 2

  if (p === "a") {
    p;  // (parameter) p: "a"

    // this *does* get narrowed!
    let foo: Foo<typeof p>;  // let foo: 1

    foo = 1;
    //foo = 2;  // ERROR: Type '2' is not assignable to type '1'.
  }
  else {
    p;  // (parameter) p: "b"

    // this *does* get narrowed!
    let foo: Foo<typeof p>;  // let foo: 2

    //foo = 1;  // ERROR: Type '1' is not assignable to type '2'.
    foo = 2;
  }
}

Link to playground

Answer 3

Answer №2

When working in TypeScript, it's important to note that control flow analysis does not impact generic type parameters. While statements like if/else, switch/case, or ternary expressions can help narrow the types of values, they do not have any effect on re-constraining generic types. This means that even though the parameter may appear to be narrowed down within the function, the generic type remains unchanged.

function foo<T extends "a" | "b">(parameter: T) {
    type Foo = T extends "a" ? 1 : 2;
    let foo: Foo;
    if (parameter === "a") foo = 1;
    else foo = 2;
}

In the example above, checking (parameter === "a") narrows the type of parameter, but it doesn't constrain the generic type T itself. As a result, the type Foo remains a conditional type instead of being strictly evaluated to a specific value.

Several open feature requests are addressing this issue and proposing ways to improve the handling of generic types in such scenarios:

microsoft/TypeScript#33912 highlights the general problem with generic conditional types and control flow analysis
microsoft/TypeScript#33014 suggests enabling safe control-flow related changes to generic types
microsoft/TypeScript#27808 recommends restricting generic type arguments to ensure implications about the generic type parameter from checking a generic value

Until these features are implemented, developers need to find workarounds for this limitation in TypeScript.

One workaround is to move away from control flow analysis and conditional types, and instead use an object indexing approach where different cases are represented as indexed access types. By transitioning code to utilize this method, TypeScript can effectively handle generic indexing operations within the type system.

function foo<T extends "a" | "b">(parameter: T) {
  type Foo = { a: 1, b: 2 }[T]
  let foo: Foo = ({ a: 1, b: 2 } as const)[parameter];
}

(It's worth noting that the const assertion is used to ensure correct type inference.)

Check out the Playground link for live code examples.

Answer 4

When working in TypeScript, it's important to note that control flow analysis does not impact generic type parameters. While statements like if/else, switch/case, or ternary expressions can help narrow the types of values, they do not have any effect on re-constraining generic types. This means that even though the parameter may appear to be narrowed down within the function, the generic type remains unchanged.

function foo<T extends "a" | "b">(parameter: T) {
    type Foo = T extends "a" ? 1 : 2;
    let foo: Foo;
    if (parameter === "a") foo = 1;
    else foo = 2;
}

In the example above, checking (parameter === "a") narrows the type of parameter, but it doesn't constrain the generic type T itself. As a result, the type Foo remains a conditional type instead of being strictly evaluated to a specific value.

Several open feature requests are addressing this issue and proposing ways to improve the handling of generic types in such scenarios:

microsoft/TypeScript#33912 highlights the general problem with generic conditional types and control flow analysis
microsoft/TypeScript#33014 suggests enabling safe control-flow related changes to generic types
microsoft/TypeScript#27808 recommends restricting generic type arguments to ensure implications about the generic type parameter from checking a generic value

Until these features are implemented, developers need to find workarounds for this limitation in TypeScript.

One workaround is to move away from control flow analysis and conditional types, and instead use an object indexing approach where different cases are represented as indexed access types. By transitioning code to utilize this method, TypeScript can effectively handle generic indexing operations within the type system.

function foo<T extends "a" | "b">(parameter: T) {
  type Foo = { a: 1, b: 2 }[T]
  let foo: Foo = ({ a: 1, b: 2 } as const)[parameter];
}

(It's worth noting that the const assertion is used to ensure correct type inference.)

Check out the Playground link for live code examples.

Is it possible for a conditional type to dictate the type it is connected

Answer №1

Answer №2

Similar questions

Using Typescript: ForOf Iteration with Unknown Value Types

Issue with rendering Base64 image array strings in FlatList component in React Native

Retrieving information from a JSON object in Angular using a specific key

A TypeScript method for accessing deeply nested properties within an object

How is it possible that the type-checker is not flagging this code?

Generating a d.ts file for images in Typescript using automation techniques

What could be the reason for my button not activating my JavaScript function?

Error encountered: The combination of NextJS and Mongoose is causing a TypeError where it is unable to read properties of undefined, specifically when trying

What is the process of creating a new array by grouping data from an existing array based on their respective IDs?

While deploying: Error 500 - The installation of dependencies was unsuccessful due to a request timeout

Eliminate any unnecessary padding from elements in angular2 components

Component in Angular2 encountering a null value

how to use all parameters except the first one in TypeScript

Can one invoke ConfirmationService from a different Service?

Steps to duplicate the package.json to the dist or build directory while executing the TypeScript compiler (tsc)

Does the TS keyof typeof <Object> rule prohibit the assignment of object.keys(<Object>)?

Efficient method to access two arrays simultaneously and combine them into an associative array in JavaScript

Encountering a script error when upgrading to rc4 in Angular 2

The content of the string within the .ts file sourced from an external JSON document

Is it necessary to implement ngOnDestroy for subjects in Angular?