Vfrdtyky

I'm running into a typing nuisance:

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 running into when loading data in the context of a React component lifecycle. Because setState should not be called on a no-longer-mounted component, I prevent the load callback from firing.

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

What you wrote is effectively the same as:

function identity<T>(v: T): 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);

No when you explicitely supply the generic parameter:

var func = identity<number>((n) => {

    // type of n is 'any'

    return n.toFixed();

});

You will get a compiler error:

Now you see, you are passing a function instead of a number.

If you explain what you are trying to do, we might be able to supply you with a resolution.

There is absolutely no nuisance. It's more like you are experiencing some fault in your logic (in your mind). Not using strict mode is another problem.

/* execute( */  identity((n) => {

    // type of n is 'any', why wouldn't it be?

    // There is no type constraint in `identity` function, 

    // hence you have absolutely no reason to expect `n` to have type `number` 

    // I commented out the wrapping by `execute` function 

    // so that it doesn't confuse you. Because, no matter

    // if it's there or not, you should first figure out

    // the shape and type of underlying expression,

    // because this is how Typescript figures them out.

    return n.toFixed();

}) /* ) */

However

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



/* execute( */ identity((n) => {

    // type of n is 'number', because we added a constraint to the type parameter `T` in `identity` function

    return n.toFixed();

}) /* ) */ 

You could also do this:

/* execute( */ identity<{(n: number): string}>((n) => {

    // type of n is 'number'

    return n.toFixed();

}) /* ) */

And

execute(identity((n: string) => {

    // this is a TS error

    // "Argument of type '(n: string) => () => string' is not 

    // assignable to parameter of type '(n: number) => string'"

    return n.toFixed;

}))

Finally, you should always use strict mode (add "strict": true to "compilerOptions" of tsconfig.json) and you will never experience such caveats.