Wrapping an anonymous function in a wrapper function in Typescript can prevent the inferred typing

Question

Wrapping an anonymous function in a wrapper function in Typescript can prevent the inferred typing

I am encountering an issue with typing while coding:

function identity<T>(v: T): T{ return v; }

function execute(fn: {(n: number):string}) {}

execute((n) => {
    // type of n is 'number'
    return n.toFixed();
})

execute(identity((n) => {
    // type of n is 'any'
    return n.toFixed();
}))

When a typed higher-order function execute receives a function, the arguments of that anonymous function are typed via inference. However, passing that anonymous function to a wrapper identity function causes those inferred types to be lost. Is there any adjustments I could make to the construction of execute or identity that can allow those typings to still be inferred?

NOTE For simplicity, identity is a pure function here. In actual practice it is not, but should have the same typing as this identity function. See checkpoint in context of question for more detail.

see it in the TS Playground

Context

This is the generic form of a problem I was facing when handling data within a React component lifecycle. To avoid calling setState on an unmounted component, I implemented logic to prevent the load callback from executing.

function loadData():Promise<MyDataType> {/*...*/}    

// Wraps the passed function (handleDataLoaded), 
// such that when the returned function is executed the 
// passed function is conditionally executed depending 
// on closure state.
function checkpoint(fn){/*...*/}

// Add data to the state of the component
function handleDataLoaded(val: MyDataType){/*...*/}



// react lifecycle hook componentDidMount
    loadData()
        .then(checkpoint(handleDataLoaded));

// react lifecycle hook componentWillUnmount 
// adjusts state of checkpoint's closure such that handleDataloaded
// is not fired after componentWillUnmount

typescript type-inference

Answer 1

Answer №1

It seems that the code you provided is essentially equivalent to:

function identity<T>(v: T){ return v; }

function execute(fn: {(n: number):string}) {}

execute((n) => {
    // type of n is 'number'
    return n.toFixed();
})

var func = identity((n) => {
    // type of n is 'any'
    return n.toFixed();
});
execute(func);

However, when you explicitly specify the generic parameter as follows:

var func = identity<number>((n) => {
    // type of n is 'any'
    return n.toFixed();
});

You will encounter a compiler error:

As you can see, you are passing a function instead of a number.

If you elaborate on your intentions, we may be able to offer a solution.

Answer 2

It seems that the code you provided is essentially equivalent to:

function identity<T>(v: T){ return v; }

function execute(fn: {(n: number):string}) {}

execute((n) => {
    // type of n is 'number'
    return n.toFixed();
})

var func = identity((n) => {
    // type of n is 'any'
    return n.toFixed();
});
execute(func);

However, when you explicitly specify the generic parameter as follows:

var func = identity<number>((n) => {
    // type of n is 'any'
    return n.toFixed();
});

You will encounter a compiler error:

As you can see, you are passing a function instead of a number.

If you elaborate on your intentions, we may be able to offer a solution.

Answer 3

Answer №2

There is no annoyance at all. It seems more like a case of encountering a flaw in your reasoning (in your thoughts). The absence of strict mode presents another complication.

/* execute( */  identity((n) => {
    // the type of n is 'any', as it would naturally be
    // There are no type constraints in the `identity` function, 
    // so there is no logical basis to anticipate `n` to have the type `number`
    // I've omitted the wrapping by the `execute` function 
    // to avoid any confusion on your part. Regardless,
    // whether it's included or not, you should first determine
    // the structure and nature of the underlying expression,
    // as this is how Typescript deduces them.
    return n.toFixed();
}) /* ) */

However

function identity<T extends {(n: number): string}>(v: T): T{ return v; }

/* execute( */ identity((n) => {
    // n is of type 'number' due to the constraint on the type parameter `T` in the `identity` function
    return n.toFixed();
}) /* ) */

You can also do this:

/* execute( */ identity<{(n: number): string}>((n) => {
    // n is of type 'number'
    return n.toFixed();
}) /* ) */

And

execute(identity((n: string) => {
    // this triggers a TS error
    // "Argument of type '(n: string) => () => string' is not 
    // assignable to parameter of type '(n: number) => string'"
    return n.toFixed;
}))

In conclusion, it is crucial to always utilize strict mode (include "strict": true in the "compilerOptions" section of tsconfig.json) to prevent encountering such issues.

Answer 4

There is no annoyance at all. It seems more like a case of encountering a flaw in your reasoning (in your thoughts). The absence of strict mode presents another complication.

/* execute( */  identity((n) => {
    // the type of n is 'any', as it would naturally be
    // There are no type constraints in the `identity` function, 
    // so there is no logical basis to anticipate `n` to have the type `number`
    // I've omitted the wrapping by the `execute` function 
    // to avoid any confusion on your part. Regardless,
    // whether it's included or not, you should first determine
    // the structure and nature of the underlying expression,
    // as this is how Typescript deduces them.
    return n.toFixed();
}) /* ) */

However

function identity<T extends {(n: number): string}>(v: T): T{ return v; }

/* execute( */ identity((n) => {
    // n is of type 'number' due to the constraint on the type parameter `T` in the `identity` function
    return n.toFixed();
}) /* ) */

You can also do this:

/* execute( */ identity<{(n: number): string}>((n) => {
    // n is of type 'number'
    return n.toFixed();
}) /* ) */

And

execute(identity((n: string) => {
    // this triggers a TS error
    // "Argument of type '(n: string) => () => string' is not 
    // assignable to parameter of type '(n: number) => string'"
    return n.toFixed;
}))

In conclusion, it is crucial to always utilize strict mode (include "strict": true in the "compilerOptions" section of tsconfig.json) to prevent encountering such issues.

Wrapping an anonymous function in a wrapper function in Typescript can prevent the inferred typing

Answer №1

Answer №2

Similar questions

The process of automatically formatting Typescript has transformed into an unfortunate auto-discarding action

Leveraging Angular's catchError method to handle errors and return

Utilize the useState() hook to add an object and display its data in a React Native

What steps do I need to take to export my TypeScript declarations to an NPM package?

Tips for obtaining a subset of `keyof T` where the value, T[K], refers to callable functions in Typescript

Is it necessary to specify the inputs property when defining an Angular @Component?

Is there a way to access URL parameters in the back-end using Node.js?

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

What are the steps for integrating Socket.IO into NUXT 3?

Having trouble integrating jQuery into an Angular CLI project

Why is it that in Angular, console.log(11) is displayed before console.log(1)?

Set the value of HTML input type radio to a nested JSON string

Jest is having difficulty locating a module while working with Next.js, resulting in

best typescript configuration for node 8 suggested

Error TS2339: Property does not exist on type 'object' - Typescript arrow function issue

Tips for ensuring session token verification remains intact upon reloading

What is the process for importing a file with an .mts extension in a CJS-first project?

Ways to update the component's state externally

Challenges when building a production version of an Expo app with Typescript

Tips for executing a type-secure object mapping in Typescript