What could be causing the type errors I am encountering while trying to resolve this Promise within a generic function?

Question

What could be causing the type errors I am encountering while trying to resolve this Promise within a generic function?

I am attempting to implement additional types within this WebSocket protocol:

type Action = {
    action: "change-or-create-state";
    response: string;
} | {
    action: "get-state";
    response: string | null;
};

/**
 * map an action to its response
 */
type ActionResponse<T extends Action["action"]> = Extract<
    Action,
    { action: T }
>["response"];

export async function doAction<
    TAction extends Action["action"]
>(action: TAction): Promise<ActionResponse<TAction>> { /* ... */ }

I am facing difficulties with the types when it comes to actually resolving that promise, though:

// data received over websocket in reality
const someDataFromAPI: string = '"hello world"'

export async function doAction<
    TAction extends Action["action"]
>(action: TAction): Promise<ActionResponse<TAction>> {
    return new Promise<ActionResponse<TAction>>((resolve) => {
        const jsonWithSpecificType: ActionResponse<TAction> = JSON.parse(someDataFromAPI);

        /** ⚠️
        Argument of type 'ActionResponse<TAction>' is not assignable to parameter of type 'ActionResponse<TAction> | PromiseLike<ActionResponse<TAction>>'.
        Type 'Extract<{ action: “get-state”; response: string | null; }, { action: TAction; }>["response"]' is not assignable to type 'ActionResponse<TAction> | PromiseLike<ActionResponse<TAction>>'.
        Type 'string | null' is not assignable to type 'ActionResponse<TAction> | PromiseLike<ActionResponse<TAction>>'.
        Type 'null' is not assignable to type 'ActionResponse<TAction> | PromiseLike<ActionResponse<TAction>>'.(2345)
        */
        resolve(jsonWithSpecificType)
    })
}

Playground link here. What could be causing the issue? Using any resolves the problem, but I would like to understand the underlying cause. My assumption is that there might be a discrepancy in maintaining the same type for TAction within and outside the arrow function.

typescript

Answer 1

Answer №1

After conducting thorough research, I have come across a potential answer to this query in microsoft/TypeScript#47233. This reference points out an issue that is similar to the one being discussed here and is categorized as a bug. It remains uncertain whether this is indeed a bug or simply a limitation based on design. If time permits, I plan to raise a new inquiry to obtain an authoritative resolution.

My analysis suggests that the complexity arises due to the involvement of generic types such as ActionResponse<TAction> and

ActionResponse<TAction> | PromiseLike<ActionResponse<TAction>>

. The compiler struggles to fully evaluate these types because they incorporate various type manipulations like union types, conditional types, and indexed accesses outlined in the TypeScript documentation. Consequently, ActionResponse<TAction> and

ActionResponse<TAction> | PromiseLike<ActionResponse<TAction>>

are perceived as somewhat "opaque" by the compiler.

While a human reviewer can easily deduce that the former type must be assignable to the latter, following the rule "X is always assignable to X | Y" with ActionResponse<T> mapped to X and

PromiseLike<ActionResponse<TAction>>

represented as Y, the compiler lacks this intuition. When the compiler reaches a point where it struggles with evaluating the types before applying the rules of union assignability, errors tend to occur.

To illustrate this behavior, consider a simplified scenario:

type F<K extends "a" | "b"> = (
    ({ x: "a"; y: "a"; } | { x: "b"; y: "b"; }) & { x: K }
)["y"];

function foo<K extends "a" | "b">(fk: F<K>): F<K> | undefined {
    return fk; // error?!
}

In this example, although it seems evident that F<K> can be assigned to

F<K> | undefined</code regardless of its specific value, the intricate definitions within <code>F

create complexity for the compiler, leading to potential errors. While I utilize an intersection approach instead of Extract for demonstration purposes, the underlying concept remains consistent.

This explanation reflects my current understanding of the situation based on extensive analysis. Should further insights emerge from a formal investigation, I will revise this response accordingly.

Explore Code in TypeScript Playground

Answer 2

After conducting thorough research, I have come across a potential answer to this query in microsoft/TypeScript#47233. This reference points out an issue that is similar to the one being discussed here and is categorized as a bug. It remains uncertain whether this is indeed a bug or simply a limitation based on design. If time permits, I plan to raise a new inquiry to obtain an authoritative resolution.

My analysis suggests that the complexity arises due to the involvement of generic types such as ActionResponse<TAction> and

ActionResponse<TAction> | PromiseLike<ActionResponse<TAction>>

. The compiler struggles to fully evaluate these types because they incorporate various type manipulations like union types, conditional types, and indexed accesses outlined in the TypeScript documentation. Consequently, ActionResponse<TAction> and

ActionResponse<TAction> | PromiseLike<ActionResponse<TAction>>

are perceived as somewhat "opaque" by the compiler.

While a human reviewer can easily deduce that the former type must be assignable to the latter, following the rule "X is always assignable to X | Y" with ActionResponse<T> mapped to X and

PromiseLike<ActionResponse<TAction>>

represented as Y, the compiler lacks this intuition. When the compiler reaches a point where it struggles with evaluating the types before applying the rules of union assignability, errors tend to occur.

To illustrate this behavior, consider a simplified scenario:

type F<K extends "a" | "b"> = (
    ({ x: "a"; y: "a"; } | { x: "b"; y: "b"; }) & { x: K }
)["y"];

function foo<K extends "a" | "b">(fk: F<K>): F<K> | undefined {
    return fk; // error?!
}

In this example, although it seems evident that F<K> can be assigned to

F<K> | undefined</code regardless of its specific value, the intricate definitions within <code>F

create complexity for the compiler, leading to potential errors. While I utilize an intersection approach instead of Extract for demonstration purposes, the underlying concept remains consistent.

This explanation reflects my current understanding of the situation based on extensive analysis. Should further insights emerge from a formal investigation, I will revise this response accordingly.

Explore Code in TypeScript Playground

Answer 3

Answer №2

It's a temporary fix for now, but I'm not completely certain why it works -

export async function performAction<
    Action extends Action["action"],
    Response = ActionResponse<Action> // <--
>(action: Action): Promise<Response> {
    return new Promise((resolve) => {
        const specificTypeData: Response = JSON.parse(someDataFromAPI)  
        resolve(specificTypeData)
    })
}

const x = performAction("change-or-create-state") // : Promise<string>
const y = performAction("get-state") // : Promise<string | null>
const z = performAction("foo") // : "foo" is not assignable to parameter of type "change-or-create-state" | "get-state"

Answer 4

It's a temporary fix for now, but I'm not completely certain why it works -

export async function performAction<
    Action extends Action["action"],
    Response = ActionResponse<Action> // <--
>(action: Action): Promise<Response> {
    return new Promise((resolve) => {
        const specificTypeData: Response = JSON.parse(someDataFromAPI)  
        resolve(specificTypeData)
    })
}

const x = performAction("change-or-create-state") // : Promise<string>
const y = performAction("get-state") // : Promise<string | null>
const z = performAction("foo") // : "foo" is not assignable to parameter of type "change-or-create-state" | "get-state"

What could be causing the type errors I am encountering while trying to resolve this Promise within a generic function?

Answer №1

Answer №2

Similar questions

Issue with TranslateModule Configuration malfunctioning

I'm encountering difficulty accessing the Index value within the template's Ref

Utilizing Eithers to effectively manage errors as they propagate through the call chain

Uniform retrieval function for interaction with API

Error in cypress configuration occurs when a plug is mistakenly defined as an import instead of a const within the cypress.config.ts file

Navigating a SwipeableDrawer in React with scrolling functionality

Prisma DB is a versatile database that excels in handling m-n

What is the reason for the removal of HTML tags in the environment when converting Angular dependencies from es2015 to esm2015 during

A guide to sorting through in-app notifications in REACT-NATIVE based on their read status

Document: include checksum in HTML

Building a hybrid application in Angular using UpgradeModule to manage controllers

Tips on invoking Bootstrap's collapse function without using JQuery

What is the best way to incorporate this in a callback function?

Angular 2 Validation Customizer

What sets apart extending and intersecting interfaces in TypeScript?

Exploring the Potential of Jest Testing for Angular 6 Services

Disable inline imports when implementing an interface in vscode by selecting the "Implement interface" option

Guide to incorporating external code in InversifyJS without direct control

Steps to modify the CSS of a custom component in Angular 8

Next.JS-13 has encountered an inappropriate middleware in its App Based Routing functionality