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

Challenges in designing components in Angular 2.0 and beyond

Tips for managing numerous nested subscriptions

Issues with Typegoose and Mongoose Enums when utilizing an array of strings

The functionality to verify the presence of a child element is not functioning correctly when using

Creating a universal timer at the application level in Angular

What is the method to have VIM recognize backticks as quotes?

Deleting a file from the assets folder in Angular for good

Error message in Angular 2: "__generator is not recognized"

Getting a date object that is three months prior to the current date in Typescript

Tips for maintaining the menu state following a refresh

Access the properties of the encapsulated component in Vue 3, allowing for IDE autocomplete support

Convert a regular element into a DebugElement within an Angular framework

Angular 13: Issue with displaying lazy loaded module containing multiple outlets in a component

Restrict or define the acceptable values for a key within an interface

What is the best way to parse JSON data with Typescript?

Sending real-time data from the tRPC stream API in OpenAI to the React client

Error: module not found in yarn

The specified type 'Observable<{}' cannot be assigned to the type 'Observable<HttpEvent<any>>'

Caution: The file path in node_modules/ngx-translate-multi-http-loader/dist/multi-http-loader.js relies on the 'deepmerge' dependency

Is it possible that React.createElement does not accept objects as valid react children?