Are strongly-typed functions as parameters possible in TypeScript?

Question

In TypeScript, I can declare a parameter of a function as a type Function. Is there a "type-safe" way of doing this that I am missing? For example, consider this:

class Foo {
    save(callback: Function) : void {
        //Do the save
        var result : number = 42; //We get a number from the save operation
        //Can I at compile-time ensure the callback accepts a single parameter of type number somehow?
        callback(result);
    }
}

var foo = new Foo();
var callback = (result: string) : void => {
    alert(result);
}
foo.save(callback);

The save callback is not type safe, I am giving it a callback function where the function's parameter is a string but I am passing it a number, and compiles with no errors. Can I make the result parameter in save a type-safe function?

TL;DR version: is there an equivalent of a .NET delegate in TypeScript?

Normy

Answer 1

Sure. A function's type consists of the types of its argument and its return type. Here we specify that the callback parameter's type must be "function that accepts a number and returns type any":

class Foo {
    save(callback: (n: number) => any) : void {
        callback(42);
    }
}
var foo = new Foo();

var strCallback = (result: string) : void => {
    alert(result);
}
var numCallback = (result: number) : void => {
    alert(result.toString());
}

foo.save(strCallback); // not OK
foo.save(numCallback); // OK

If you want, you can define a type alias to encapsulate this:

type NumberCallback = (n: number) => any;

class Foo {
    // Equivalent
    save(callback: NumberCallback) : void {
        callback(42);
    }
}

Clastic

(n: number) => any means any function signature? – Barranca

@nikkwong it means the function takes one parameter (a number) but the return type is not restricted at all (could be any value, or even void) – Maddie

What is the point of n in this syntax? Wouldn't the input and output types alone be sufficient? – Astrogation

So, union types will does works? save(callback: (n: number) => any | string) : void { callback(42); } – Coachandfour

One side effect between using inline functions vs named functions (answer below vs this answer) is the "this" variable is undefined with the named function whereas it is defined within the inline function. No surprise for JavaScript coders but definitely not obvious to other coding backgrounds. – Locution

@YuhuanJiang This post might be of interest to you – Stereography

Answer 2

Here are TypeScript equivalents of some common .NET delegates:

interface Action<T>
{
    (item: T): void;
}

interface Func<T,TResult>
{
    (item: T): TResult;
}

Artiste

Probably useful to look at but it would be an anti-pattern to actually use such types. Anyway those look more like Java SAM types than C# delegates. Of course they aren't and they are equivalent to the type alias form which is just more elegant for functions – Lanner

@AluanHaddad could you elaborate on why you would think this an anti- pattern? – Preponderate

The reason is TypeScript has a concise function type literal syntax that obviates the need for such interfaces. In C# delegates are nominal, but the Action and Func delegates both obviate most of the need for specific delegate types and, interestingly, give C# a of semblance of structural typing. The downside to these delegates is that their names convey no meaning but the other advantages generally outweigh this. In TypeScript we simply don't need these types. So the anti-pattern would be function map<T, U>(xs: T[], f: Func<T, U>). Prefer function map<T, U>(xs: T[], f: (x: T) => U) – Lanner

It's a matter of taste, as these are equivalent forms in a language that doesn't have run-time types. Nowadays you can also use type aliases instead of interfaces. – Artiste

One reason to prefer Func<A, B> over (arg: A) => B is syntactic precedence - anywhere you would need to use brackets like ((arg: A) => B), the former doesn't need the extra brackets. That said, I tend to prefer more specific types, e.g. type Predicate<T> = (x: T) => boolean, since these add more readability. – Wivina

Answer 3

type FunctionName = (n: inputType) => any;

class ClassName {
    save(callback: FunctionName) : void {
        callback(data);
    }
}

This surely aligns with the functional programming paradigm.

Ramiah

Answer 4

I realize this post is old, but there's a more compact approach that is slightly different than what was asked, but may be a very helpful alternative. You can essentially declare the function in-line when calling the method (Foo's save() in this case). It would look something like this:

class Foo {
    save(callback: (n: number) => any) : void {
        callback(42)
    }

    multipleCallbacks(firstCallback: (s: string) => void, secondCallback: (b: boolean) => boolean): void {
        firstCallback("hello world")

        let result: boolean = secondCallback(true)
        console.log("Resulting boolean: " + result)
    }
}

var foo = new Foo()

// Single callback example.
// Just like with @RyanCavanaugh's approach, ensure the parameter(s) and return
// types match the declared types above in the `save()` method definition.
foo.save((newNumber: number) => {
    console.log("Some number: " + newNumber)

    // This is optional, since "any" is the declared return type.
    return newNumber
})

// Multiple callbacks example.
// Each call is on a separate line for clarity.
// Note that `firstCallback()` has a void return type, while the second is boolean.
foo.multipleCallbacks(
    (s: string) => {
         console.log("Some string: " + s)
    },
    (b: boolean) => {
        console.log("Some boolean: " + b)
        let result = b && false

        return result
    }
)

The multipleCallback() approach is very useful for things like network calls that may succeed or fail. Again assuming a network call example, when multipleCallbacks() is called, behavior for both a success and failure can be defined in one spot, which lends itself to greater clarity for future code readers.

Generally, in my experience, this approach lends itself to being more concise, less clutter, and greater clarity overall.

Good luck all!

Salesman

Answer 5

In TS we can type functions in the in the following manners:

Functions types/signatures

This is used for real implementations of functions/methods it has the following syntax:

(arg1: Arg1type, arg2: Arg2type) : ReturnType

Example:

function add(x: number, y: number): number {
    return x + y;
}

class Date {
  setTime(time: number): number {
   // ...
  }

}

Function Type Literals

Function type literals are another way to declare the type of a function. They're usually applied in the function signature of a higher-order function. A higher-order function is a function which accepts functions as parameters or which returns a function. It has the following syntax:

(arg1: Arg1type, arg2: Arg2type) => ReturnType

Example:

type FunctionType1 = (x: string, y: number) => number;

class Foo {
    save(callback: (str: string) => void) {
       // ...
    }

    doStuff(callback: FunctionType1) {
       // ...
    }

}

Zymo

Answer 6

If you define function type first then it would be looked like

type Callback = (n: number) => void;

class Foo {
    save(callback: Callback) : void {        
        callback(42);
    }
}

var foo = new Foo();
var stringCallback = (result: string) : void => {
    console.log(result);
}

var numberCallback = (result: number) : void => {
    console.log(result);
}

foo.save(stringCallback); //--will be showing error
foo.save(numberCallback);

Without function type by using plain property syntax it would be:

class Foo {
    save(callback: (n: number) => void) : void {        
        callback(42);
    }
}

var foo = new Foo();
var stringCallback = (result: string) : void => {
    console.log(result);
}

var numberCallback = (result: number) : void => {
    console.log(result);
}

foo.save(stringCallback); //--will be showing error
foo.save(numberCallback);

If you want by using an interface function like c# generic delegates it would be:

interface CallBackFunc<T, U>
{
    (input:T): U;
};

class Foo {
    save(callback: CallBackFunc<number,void>) : void {        
        callback(42);
    }
}

var foo = new Foo();
var stringCallback = (result: string) : void => {
    console.log(result);
}

var numberCallback = (result: number) : void => {
    console.log(result);
}

let strCBObj:CallBackFunc<string,void> = stringCallback;
let numberCBObj:CallBackFunc<number,void> = numberCallback;

foo.save(strCBObj); //--will be showing error
foo.save(numberCBObj);

Ascites

Answer 7

Because you can't easily union a function definition and another data type, I find having these types around useful to strongly type them. Based on Drew's answer.

type Func<TArgs extends any[], TResult> = (...args: TArgs) => TResult; 
//Syntax sugar
type Action<TArgs extends any[]> = Func<TArgs, undefined>; 

Now you can strongly type every parameter and the return type! Here's an example with more parameters than what is above.

save(callback: Func<[string, Object, boolean], number>): number
{
    let str = "";
    let obj = {};
    let bool = true;
    let result: number = callback(str, obj, bool);
    return result;
}

Now you can write a union type, like an object or a function returning an object, without creating a brand new type that may need to be exported or consumed.

//THIS DOESN'T WORK
let myVar1: boolean | (parameters: object) => boolean;

//This works, but requires a type be defined each time
type myBoolFunc = (parameters: object) => boolean;
let myVar1: boolean | myBoolFunc;

//This works, with a generic type that can be used anywhere
let myVar2: boolean | Func<[object], boolean>;

Resendez

Maybe this was on a previous version of TS but, let myVar1: boolean | (parameters: object) => boolean; doesn't work because you need to add parenthesis around the function => let myVar1: boolean | ((parameters: object) => boolean); – Sailfish

Answer 8

Besides what other said, a common problem is to declare the types of the same function that is overloaded. Typical case is EventEmitter on() method which will accept multiple kind of listeners. Similar could happen When working with redux actions - and there you use the action type as literal to mark the overloading, In case of EventEmitters, you use the event name literal type:

interface MyEmitter extends EventEmitter {
  on(name:'click', l: ClickListener):void
  on(name:'move', l: MoveListener):void
  on(name:'die', l: DieListener):void
  //and a generic one
  on(name:string, l:(...a:any[])=>any):void
}

type ClickListener = (e:ClickEvent)=>void
type MoveListener = (e:MoveEvent)=>void
... etc

// will type check the correct listener when writing something like:
myEmitter.on('click', e=>...<--- autocompletion

Cyndycynera

Answer 9

function callbackTesting(callbacks: {onYes: (data: any) => void,onNo: (data: any) => void,onError: (err: any) => void,}, type: String){
        switch(type){
            case "one": 
            callbacks.onYes("Print yes");
            break;
            case "two": 
            callbacks.onNo("Print no");
            break;
            default:
            callbacks.onError("Print error");
            break;
        }
    }

    const onYes1 = (data: any) : void => {
        console.log(data);
    }
    const onNo1 = (data: any) : void => {
        console.log(data);
    }
    const onError1 = (data: any) : void => {
        console.log(data);
    }



    callbackTesting({onYes: function (data: any)  {onYes1(data);},onNo: function (data: any)  {onNo1(data);},onError: function (data: any)  {onError1(data);}}, "one");

    callbackTesting({onYes: function (data: any)  {onYes1(data);},onNo: function (data: any)  {onNo1(data);},onError: function (data: any)  {onError1(data);}}, "two");

    callbackTesting({onYes: function (data: any)  {onYes1(data);},onNo: function (data: any)  {onNo1(data);},onError: function (data: any)  {onError1(data);}}, "cfhvgjbhkjlkm");

Slaby