A function in Typescript is created to handle diverse input types in a generic manner

Question

A function in Typescript is created to handle diverse input types in a generic manner

My goal is to create a function that can handle various input types for abstraction purposes.

type ContentA = string

type ContentB = number

type InputA = {
 name: 'method_a'
 content: ContentA
}

type InputB = {
 name: 'method_b'
 content: ContentB
}

type Input = InputA | InputB

Each type of input corresponds to a different method:

const my_methods = {
 method_a: (content:ContentA) => {
  // ...
 },
 method_b: (content:ContentB) => {
  // ...
 }
}

Now I need to create a generic function that can handle all the possible inputs, as there could be many. Currently, there are only two types of inputs defined, but in my actual project, there are around 16.

I attempted to implement this kind of function, but encountered a compilation error:

function foo(input:Input){
 return my_methods[input.name](input.content);
                             // ^
                             // | Argument of type 'string | number' is not  
                             // | assignable to parameter of type 'never'.
                             // | Type 'string' is not assignable to type 'never'.
}

Is there a way for Typescript to understand that the argument passed to the method based on input.name will always match with input.content? How can I resolve this issue?

Playground link

typescript typescript-generics type-inference

Answer 1

Answer №1

This challenge presented an intriguing problem, and after some thoughtful consideration, I believe I've devised a satisfactory solution.

My approach involved transforming the initial union type Input into generics instead of relying on discriminated unions based on literals, as those are more effective with actual values rather than variables.

To start, let's define a type that encompasses all potential values for the name property:

type Names = Input["name"];

Subsequently, we can establish a "lookup" generic type that correlates the given name type argument with the corresponding content type. For instance, ContentByName<"method_a"> would refer to ContentA.

type ContentByName<TName extends Names> = {
  [i in Input as i["name"]]: i["content"];
}[TName];

With this setup, we create a specific type tailored to your my_methods object, ensuring clarity for the compiler regarding the associations between names and content types:

type Methods = { [name in Names]: (content: ContentByName<name>) => void };

const my_methods: Methods = { // <-- introduced in your code here
  // ...
}

Finally, your foo function must also be made generic, necessitating a generic rendition of the Input type.

type InputByName<TName extends Names> = {
  name: TName;
  content: ContentByName<TName>;
};

function foo<TName extends Names>(input: InputByName<TName>) {  // <-- included
  //...
}

It's worth noting that you can still invoke this function with a regular Input just like before. This remains perfectly valid:

function foo_old(input: Input) {
    return foo(input);
}

No changes were actually made to the types themselves; we simply facilitated the compiler's understanding of them.

For the modified version along with these alterations, visit the playground link demonstrating these changes.

Answer 2

This challenge presented an intriguing problem, and after some thoughtful consideration, I believe I've devised a satisfactory solution.

My approach involved transforming the initial union type Input into generics instead of relying on discriminated unions based on literals, as those are more effective with actual values rather than variables.

To start, let's define a type that encompasses all potential values for the name property:

type Names = Input["name"];

Subsequently, we can establish a "lookup" generic type that correlates the given name type argument with the corresponding content type. For instance, ContentByName<"method_a"> would refer to ContentA.

type ContentByName<TName extends Names> = {
  [i in Input as i["name"]]: i["content"];
}[TName];

With this setup, we create a specific type tailored to your my_methods object, ensuring clarity for the compiler regarding the associations between names and content types:

type Methods = { [name in Names]: (content: ContentByName<name>) => void };

const my_methods: Methods = { // <-- introduced in your code here
  // ...
}

Finally, your foo function must also be made generic, necessitating a generic rendition of the Input type.

type InputByName<TName extends Names> = {
  name: TName;
  content: ContentByName<TName>;
};

function foo<TName extends Names>(input: InputByName<TName>) {  // <-- included
  //...
}

It's worth noting that you can still invoke this function with a regular Input just like before. This remains perfectly valid:

function foo_old(input: Input) {
    return foo(input);
}

No changes were actually made to the types themselves; we simply facilitated the compiler's understanding of them.

For the modified version along with these alterations, visit the playground link demonstrating these changes.

Answer 3

Answer №2

It's important to note that the code provided in the playground differs significantly from what was mentioned in the original question.

The main issue with this snippet is the lack of effective type narrowing. One way to address this would be by utilizing a switch statement:

function bar(input: Input) {
    switch(input.name) {
        case 'method_x': {
            // At this point, input.content is known to be a string
            console.log(input.content)
            break;
        }
        case 'method_y': {
            // Here, input.content is confirmed to be a number
            console.log(input.content)
            break;
        }
    }
}

Answer 4

It's important to note that the code provided in the playground differs significantly from what was mentioned in the original question.

The main issue with this snippet is the lack of effective type narrowing. One way to address this would be by utilizing a switch statement:

function bar(input: Input) {
    switch(input.name) {
        case 'method_x': {
            // At this point, input.content is known to be a string
            console.log(input.content)
            break;
        }
        case 'method_y': {
            // Here, input.content is confirmed to be a number
            console.log(input.content)
            break;
        }
    }
}

Answer 5

Answer №3

Here is one potential solution that I can offer:

Utilize the playground link

const isOfTypeInputA = (input:Input): input is InputA => {
    return input.name === 'method_a';
}

const isOfTypeInputB = (input:Input): input is InputB => {
    return input.name === 'method_b';
}

function foo(input:Input){
    if (isOfTypeInputA(input)) {
        return my_methods.method_a(input.content);
    } else if (isOfTypeInputB(input)) {
        return my_methods.method_b(input.content);
    } else {
        throw new Error(`foo Not supported input`);
    }
}

Answer 6

Here is one potential solution that I can offer:

Utilize the playground link

const isOfTypeInputA = (input:Input): input is InputA => {
    return input.name === 'method_a';
}

const isOfTypeInputB = (input:Input): input is InputB => {
    return input.name === 'method_b';
}

function foo(input:Input){
    if (isOfTypeInputA(input)) {
        return my_methods.method_a(input.content);
    } else if (isOfTypeInputB(input)) {
        return my_methods.method_b(input.content);
    } else {
        throw new Error(`foo Not supported input`);
    }
}

Answer 7

Answer №4

It seems like determining the type of my_methods[input.name] is a challenge as it cannot be strictly defined at compile time beyond

(ContentA) => void | (ContentB) => void

.

To address this, a cast is necessary:

function foo(input:Input){
 return my_methods[input.name](input.content as any);
 //                                          ^^^^^^
}

Some other solutions presented do not require a cast and instead rely on control flow for type narrowing, which are also valid options depending on context and preference.

If you choose to continue with the current method, one enhancement could be to define the type of my_methods more precisely so that the compiler can verify if the keys and argument types align with the potential Input types:

type InputMethods = {
    [I in Input as I['name']]: (content: I['content']) => void
}

const my_methods: InputMethods = {
    method_a: (content: ContentA) => {
        // ...
    },
    method_b: (content: ContentB) => {
        // ...
    }
    
}

Playground

Answer 8

It seems like determining the type of my_methods[input.name] is a challenge as it cannot be strictly defined at compile time beyond

(ContentA) => void | (ContentB) => void

.

To address this, a cast is necessary:

function foo(input:Input){
 return my_methods[input.name](input.content as any);
 //                                          ^^^^^^
}

Some other solutions presented do not require a cast and instead rely on control flow for type narrowing, which are also valid options depending on context and preference.

If you choose to continue with the current method, one enhancement could be to define the type of my_methods more precisely so that the compiler can verify if the keys and argument types align with the potential Input types:

type InputMethods = {
    [I in Input as I['name']]: (content: I['content']) => void
}

const my_methods: InputMethods = {
    method_a: (content: ContentA) => {
        // ...
    },
    method_b: (content: ContentB) => {
        // ...
    }
    
}

Playground

A function in Typescript is created to handle diverse input types in a generic manner

Answer №1

Answer №2

Answer №3

Answer №4

Similar questions

The process of importing does not produce the anticipated System.register

Positioning the box at the exact middle of the screen

Is there a way to access the final child element within a mat-accordion component using Material-UI and Angular 8?

A guide to mocking Prisma using Jest mock functionality

I keep encountering the issue where nothing seems to be accessible

There was an issue while attempting to differentiate '[object Object]'. Ionic only allows arrays and iterables for this operation

Outdated compiler module in the latest version of Angular (v13)

Using Angular to access HTML content through the .ts file

Tips for invoking a function from one React component to another component

Defining a JSON file interface in Angular to populate a dropdown box with dependencies

What is the process for transferring a function to reducers in Redux Toolkit?

Supplier for a module relying on data received from the server

Issue with loading React Router custom props array but custom string works fine

Patience is key as you await the completion of an API call in Angular 14

Creating a type or interface within a class in TypeScript allows for encapsulation of

I encountered a TS error warning about a possible null value, despite already confirming that the value

The conditional type in TypeScript is malfunctioning

What steps are involved in launching an outdated Angular project?

The color syntax in the text editor of Visual Studio 2022 is being lost when casting an interface

"Experiencing sluggish performance with VSCode while using TypeScript and Styled Components