Determining function return property type in Typescript by mapping interface argument property

Question

Determining function return property type in Typescript by mapping interface argument property

In order to manage messaging between the browser and a web worker, I have developed a generic class. Each side creates a class that can send specific messages and acknowledge them on the other side with a returned result in a payload. The implementation is currently working perfectly, and I've implemented an interface mapping to facilitate message sending.

However, I am facing a challenge when it comes to inferring the return type based on the interface mapping passed as an argument to the function.

Below is a link to the playground showcasing the interfaces, classes, and their implementations.

I am specifically struggling with the 'send' function:

messages.send({ action: MessageAction.Init, data: { scripts: [] } }).then(data => {
  // need to infer the return type from the action.
  console.log(data);
});

Essentially, instead of returning void from the playground, I would like it to automatically determine that 'data' is actually

AcknowledgeMessageData<InitReturn>

because the 'action' property of the argument is 'init' (currently not generic). Therefore, the object structure should look like this:

{
   isSuccess: true,
   result: {
      someRandomProperty: '',
      anotherProperty: 0
   }
}

Different actions would lead to different generic properties for 'result'.

Playground

Currently, I'm unable to figure out how to trigger the inference based on the argument's property and apply it to the return value's property.

Edit: added minimal reproduction

enum Action {
    Ack = 'ack',
    Init = 'init'
}

interface BaseMessage {
    action: Action;
}

interface AckBaseMessage extends BaseMessage {
    action: Action.Ack;
}

interface InitBaseMessage extends BaseMessage {
    action: Action.Init;
}

interface MessageDataMapping {
    [Action.Ack]: AckBaseMessage;
    [Action.Init]: InitBaseMessage;
}

export type Message = { [K in Action]: MessageDataMapping[K] }[Action];

async function send(payload: Message) {
    return thisWouldBeReturnedFromWebWorker(payload);
}

async function thisWouldBeReturnedFromWebWorker(payload: Message): Promise<any> {
    if (payload.action === Action.Init) {
        return {
            action: Action.Init,
            result: {
                somePropertiesHere: true
            }
        };
    }

    return { action: Action.Ack, result: { isSuccess: true } }
}

send({ action: Action.Init }).then(response => {
    response.result.somePropertiesHere

    response.result.isSuccess
});

typescript

Answer 1

Answer №1

To tackle this, my approach would involve defining the call signature for send() as a generic function that works on the type parameter K, constrained to Action, which corresponds to the action property of the payload parameter:

declare function send<K extends Action>(payload: Message<K>): Promise<Return<K>>;

Here, the input type is Message<K> and the output type is Promise<Return<K>>. Definitions for Message<K> and Return<K> need to be established. Let's begin with Message<K>:

type Message<K extends Action> =
    { [P in K]: { action: P } }[K]

This type is known as a distributive object type introduced in microsoft/TypeScript#47109. It functions as a mapped type which is immediately indexed into. The goal here is to have Message<Action.Init> represent {action: Action.Init}, and Message<Action.Ack> denote {action: Action.Ack}, while

Message<Action.Init | Action.Ack>

represents the union of Message<Action.Init> and Message<Action.Ack>. This operation distributes over unions within the input.

The definition for Return<K> is slightly more complex as it involves retrieving the result property from a helper interface:

interface ReturnMap {
    [Action.Init]: { somePropertiesHere: boolean };
    [Action.Ack]: { isSuccess: boolean }
}

type Return<K extends Action> = { [P in K]:
    { action: K, result: ReturnMap[K] }
}[K];

Despite the complexity, the concept remains similar. Note that while the current structure of Message<K> may seem intricate for its purpose, additional properties can always be added based on K using something akin to a MessageMap interface, similar to how

ReturnMap</code is utilized.</p>
<hr />
<p>With the defined call signature, calls to <code>send()

now align with your requirements:

send({ action: Action.Init }).then(response => {
    response.result
    //       ^?(property) result: { somePropertiesHere: boolean; }
});
send({ action: Action.Ack }).then(response => {
    response.result
    //       ^?(property) result: { isSuccess: boolean; }
});

However, an issue arises inside the implementation of send() where the compiler fails to recognize the specific return values as the correct generic type:

async function send<K extends Action>(payload: Message<K>): Promise<Return<K>> {
    if (payload.action === Action.Init) {
        return { // error! Type 'Action.Init' is not assignable to type 'K'.
            action: Action.Init,
            result: {
                somePropertiesHere: true
            }
        };
    }

    return { action: Action.Ack, result: { isSuccess: true } } // error!
    //     Type 'Action.Ack' is not assignable to type 'K'.
}

Current limitations in TypeScript prevent the compiler from recognizing changes in the actual value of a generic type K, leading to uncertainties regarding the exact type of the returned value despite narrowing down the type of payload.action. Though there are suggestions for improvement like microsoft/TypeScript#33014, they haven't been incorporated yet.

A workaround involves utilizing type assertions to overcome this hurdle:

async function send<K extends Action>(payload: Message<K>): Promise<Return<K>> {
    if (payload.action === Action.Init) {
        return {
            action: Action.Init,
            result: {
                somePropertiesHere: true
            }
        } as Return<K>;
    }
    return { action: Action.Ack, result: { isSuccess: true } } as Return<K>
}

While this solution suppresses compilation errors by essentially stating "trust me, this return value is of type Return<K>", caution should be exercised to ensure the validity of the assertion.

An alternative workaround involves completing the refactoring process by incorporating both the types and implementations. This strategic update allows for the relationship between input and output types to be implemented effectively:

const ioFuncs: { [P in Action]: (i: Message<P>) => Return<P> } = {
    init: (payload) => ({ action: Action.Init, result: { somePropertiesHere: true } }),
    ack: (payload) => ({ action: Action.Ack, result: { isSuccess: true } });
}

async function send<K extends Action>(payload: Message<K>): Promise<Return<K>> {
    return ioFuncs[payload.action](payload);
}

By explicitly mapping over P in Action, the ioFuncs variable operates based on Message and Return. Ultimately, the implementation of send() entails fetching the appropriate property from ioFuncs and calling it with the payload. Type-checking verifies that ioFuncs[payload.action] adheres to the single type

(i: Message<P>) => Return<P>

. Consequently, as payload is of type Message, the function returns Return.

Although more intricate than type assertions, this method helps detect mistakes that assertions might overlook. In case of errors such as interchanging values within init and ack properties, the compiler will flag and signal the inconsistency:

const badIoFuncs: { [P in Action]: (i: Message<P>) => Return<P> } = {
    ack: (payload) => ({ action: Action.Init, result: { somePropertiesHere: true } }), 
    init: (payload) => ({ action: Action.Ack, result: { isSuccess: true } });
} // errors!

Playground link to code

Answer 2

To tackle this, my approach would involve defining the call signature for send() as a generic function that works on the type parameter K, constrained to Action, which corresponds to the action property of the payload parameter:

declare function send<K extends Action>(payload: Message<K>): Promise<Return<K>>;

Here, the input type is Message<K> and the output type is Promise<Return<K>>. Definitions for Message<K> and Return<K> need to be established. Let's begin with Message<K>:

type Message<K extends Action> =
    { [P in K]: { action: P } }[K]

This type is known as a distributive object type introduced in microsoft/TypeScript#47109. It functions as a mapped type which is immediately indexed into. The goal here is to have Message<Action.Init> represent {action: Action.Init}, and Message<Action.Ack> denote {action: Action.Ack}, while

Message<Action.Init | Action.Ack>

represents the union of Message<Action.Init> and Message<Action.Ack>. This operation distributes over unions within the input.

The definition for Return<K> is slightly more complex as it involves retrieving the result property from a helper interface:

interface ReturnMap {
    [Action.Init]: { somePropertiesHere: boolean };
    [Action.Ack]: { isSuccess: boolean }
}

type Return<K extends Action> = { [P in K]:
    { action: K, result: ReturnMap[K] }
}[K];

Despite the complexity, the concept remains similar. Note that while the current structure of Message<K> may seem intricate for its purpose, additional properties can always be added based on K using something akin to a MessageMap interface, similar to how

ReturnMap</code is utilized.</p>
<hr />
<p>With the defined call signature, calls to <code>send()

now align with your requirements:

send({ action: Action.Init }).then(response => {
    response.result
    //       ^?(property) result: { somePropertiesHere: boolean; }
});
send({ action: Action.Ack }).then(response => {
    response.result
    //       ^?(property) result: { isSuccess: boolean; }
});

However, an issue arises inside the implementation of send() where the compiler fails to recognize the specific return values as the correct generic type:

async function send<K extends Action>(payload: Message<K>): Promise<Return<K>> {
    if (payload.action === Action.Init) {
        return { // error! Type 'Action.Init' is not assignable to type 'K'.
            action: Action.Init,
            result: {
                somePropertiesHere: true
            }
        };
    }

    return { action: Action.Ack, result: { isSuccess: true } } // error!
    //     Type 'Action.Ack' is not assignable to type 'K'.
}

Current limitations in TypeScript prevent the compiler from recognizing changes in the actual value of a generic type K, leading to uncertainties regarding the exact type of the returned value despite narrowing down the type of payload.action. Though there are suggestions for improvement like microsoft/TypeScript#33014, they haven't been incorporated yet.

A workaround involves utilizing type assertions to overcome this hurdle:

async function send<K extends Action>(payload: Message<K>): Promise<Return<K>> {
    if (payload.action === Action.Init) {
        return {
            action: Action.Init,
            result: {
                somePropertiesHere: true
            }
        } as Return<K>;
    }
    return { action: Action.Ack, result: { isSuccess: true } } as Return<K>
}

While this solution suppresses compilation errors by essentially stating "trust me, this return value is of type Return<K>", caution should be exercised to ensure the validity of the assertion.

An alternative workaround involves completing the refactoring process by incorporating both the types and implementations. This strategic update allows for the relationship between input and output types to be implemented effectively:

const ioFuncs: { [P in Action]: (i: Message<P>) => Return<P> } = {
    init: (payload) => ({ action: Action.Init, result: { somePropertiesHere: true } }),
    ack: (payload) => ({ action: Action.Ack, result: { isSuccess: true } });
}

async function send<K extends Action>(payload: Message<K>): Promise<Return<K>> {
    return ioFuncs[payload.action](payload);
}

By explicitly mapping over P in Action, the ioFuncs variable operates based on Message and Return. Ultimately, the implementation of send() entails fetching the appropriate property from ioFuncs and calling it with the payload. Type-checking verifies that ioFuncs[payload.action] adheres to the single type

(i: Message<P>) => Return<P>

. Consequently, as payload is of type Message, the function returns Return.

Although more intricate than type assertions, this method helps detect mistakes that assertions might overlook. In case of errors such as interchanging values within init and ack properties, the compiler will flag and signal the inconsistency:

const badIoFuncs: { [P in Action]: (i: Message<P>) => Return<P> } = {
    ack: (payload) => ({ action: Action.Init, result: { somePropertiesHere: true } }), 
    init: (payload) => ({ action: Action.Ack, result: { isSuccess: true } });
} // errors!

Playground link to code

Determining function return property type in Typescript by mapping interface argument property

Answer №1

Similar questions

Learn how to mock asynchronous calls in JavaScript unit testing using Jest

Verify if the property in every element of the array is not empty

Having trouble with Vue i18n and TypeScript: "The '$t' property is not recognized on the 'VueConstructor' type." Any suggestions on how to resolve this issue?

Simulating Express Requests using ts-mockito in Typescript

Following the migration to Typescript, the React component is having trouble locating the redux store props and actions

What advantages does utilizing Jasmine Spy Object provide in Angular Unit Testing?

Error encountered: No matching overload found for MUI styled TypeScript

retrieve data from URL parameters (navigation backward)

Troubleshooting issue with Material UI icons in React application with Typescript

The child element is triggering an output event that is in turn activating a method within the parent

Create a debounce click directive for buttons in a TypeScript file

Attempting to authenticate with Next.js using JWT in a middleware is proving to be unsuccessful

The module 'AppModule' is throwing an error with the import of 'MatDialogRef' which is causing unexpected value. To resolve this issue, make sure to include a @

Is there a way to determine if a browser's Storage object is localStorage or sessionStorage in order to effectively handle static and dynamic secret keys within a client?

Is it necessary to 'type assert' the retrieved data in Axios if I have already specified the return type in the function declaration?

Tips for Using Typescript Instance Fields to Prevent Undefined Values

Utilize Angular's Reactive Form feature to track changes in Form Control instances within a Form Array and calculate the total value dynamically

Sequelize Date Range Error When Using Op.between with TypeScript

Vite HMR causes Vue component to exceed the maximum number of recursive updates

Error encountered in azure devops preventing successful execution: "npm ERR! code ELIFECYCLE"