Different categories of properties within a generic function

Question

Different categories of properties within a generic function

I'm attempting to modify certain fields of my object using field names. Here is the code snippet I have written:

interface Foo {
    a: number[],
    b: string[],
}

type Bar = { [T in keyof Foo] : (arg : Foo[T]) => Foo[T] }

function test<T extends keyof Foo>(field: T) {
    const foo : Foo = {
        a: [],
        b: [],
    };

    const bar: Bar = {
        a: arg => /* some code */ [],
        b: arg => /* some code */ [],
    };

    foo[field] = bar[field](foo[field]);
}

However, when executing bar[field](foo[field]), I receive the following error message:

Argument of type 'Foo[T]' is not assignable to parameter of type 'number[] & string[]'.
  Type 'number[] | string[]' is not assignable to type 'number[] & string[]'.
    Type 'number[]' is not assignable to type 'number[] & string[]'.
      Type 'number[]' is not assignable to type 'string[]'.
        Type 'number' is not assignable to type 'string'.
          Type 'Foo[T]' is not assignable to type 'number[]'.
            Type 'number[] | string[]' is not assignable to type 'number[]'.
              Type 'string[]' is not assignable to type 'number[]'.
                Type 'string' is not assignable to type 'number'

Shouldn't TypeScript infer that with the same T, Foo[T] and Parameters<Bar[T]> should hold the same value?

typescript generics types

Answer 1

Answer №1

It would be helpful if the compiler could recognize this, but unfortunately, it doesn't. This issue is often referred to as "correlated types" or "correlated records". The compiler views foo[field] and bar[field] as union-typed entities, which is technically correct. However, it treats their types independently, meaning that foo[field] could potentially be of type number[], while bar[field] might be a function accepting string[]. It fails to acknowledge that the type of foo[field] is correlated with the type of bar[field] in such a way that determining one automatically determines the other. There's an ongoing issue, mentioned in microsoft/TypeScript#30581 (which I personally reported), proposing the inclusion of support for correlated types. However, it remains uncertain whether this feature will ever be implemented or how it would work.

Presently, the only available solutions are workarounds. The two workarounds highlighted in the aforementioned issue include: incorporating redundant code to guide the compiler through various possibilities and ensure type safety, or utilizing type assertions to sacrifice some degree of type safety in favor of brevity. In your code, these approaches would look something like this:

// redundant code
const f: keyof Foo = field;
switch (f) {
   case "a":
      foo[f] = bar[f](foo[f]);
      break;
   case "b":
      foo[f] = bar[f](foo[f]);
      break;
}

// type assertion
foo[field] = (bar[field] as <T>(arg: T) => T)(foo[field]);

I typically opt for the type assertion method. Hopefully, this information proves useful to you; best of luck!

Link to code

Answer 2

It would be helpful if the compiler could recognize this, but unfortunately, it doesn't. This issue is often referred to as "correlated types" or "correlated records". The compiler views foo[field] and bar[field] as union-typed entities, which is technically correct. However, it treats their types independently, meaning that foo[field] could potentially be of type number[], while bar[field] might be a function accepting string[]. It fails to acknowledge that the type of foo[field] is correlated with the type of bar[field] in such a way that determining one automatically determines the other. There's an ongoing issue, mentioned in microsoft/TypeScript#30581 (which I personally reported), proposing the inclusion of support for correlated types. However, it remains uncertain whether this feature will ever be implemented or how it would work.

Presently, the only available solutions are workarounds. The two workarounds highlighted in the aforementioned issue include: incorporating redundant code to guide the compiler through various possibilities and ensure type safety, or utilizing type assertions to sacrifice some degree of type safety in favor of brevity. In your code, these approaches would look something like this:

// redundant code
const f: keyof Foo = field;
switch (f) {
   case "a":
      foo[f] = bar[f](foo[f]);
      break;
   case "b":
      foo[f] = bar[f](foo[f]);
      break;
}

// type assertion
foo[field] = (bar[field] as <T>(arg: T) => T)(foo[field]);

I typically opt for the type assertion method. Hopefully, this information proves useful to you; best of luck!

Link to code

Different categories of properties within a generic function

Answer №1

Similar questions

Tips for managing Razorpay responses in Angular 2

Angular 9 Issue: Failure to Display Nested Mat-Tree Children

What do you think about gulp-typescript and the latest @types typings for TypeScript?

The Value Entered in Angular is Unsaved

transmit data from Node.js Express to Angular application

Mismatched non-intersecting categories with TypeScript

The validator function in FormArray is missing and causing a TypeError

Discovering Type Definitions in Nuxt.js Project Without Manual Imports in VSCode: A Step-by-Step Guide

Instructions for opening a URL in a new tab using Angular

Encountering a 405 Error While Trying to Detect Location in Angular 7

Calculate the variance between two variables

The intended 'this' keyword is unfortunately replaced by an incorrect '

Typescript error when using fill or justify prop in React-bootstrap with Typescript

How to stop a method in Angular2 when a specific response is received?

Access SCSS variable values in Angular HTML or TypeScript files

The validation for decimal numbers fails to function when considering the length

What could be the cause of this malfunction in the Angular Service?

Drizzle ORM retrieve unique string that is not a database column

Choosing a single element through viewChild using the "#" selector in Angular 2

Extending Enums in Typescript: A Comprehensive Guide