Introduction

Yes, strongly typed functions as parameters are not only possible in TypeScript, they are one of the language's most useful features. You can describe the argument types, return type, optional parameters, generic relationships, and even overloaded behavior of a callback passed into another function.

The Basic Function Type Syntax

The simplest way is to write the callback signature inline:

1function runWithName(callback: (name: string) => void): void {
2  callback("Swift");
3}
4
5runWithName((name) => {
6  console.log(name.toUpperCase());
7});

Here, TypeScript enforces that the callback accepts a string and returns void.

Reusing a Named Function Type

If the same callback shape appears in several places, give it a name:

1type NameHandler = (name: string) => void;
2
3function greet(handler: NameHandler): void {
4  handler("TypeScript");
5}

This makes APIs easier to read and keeps the function contract consistent across files.

Strong Typing Works in Both Directions

TypeScript checks both:

• what the caller passes in
• how the callback is used inside the function

For example, this is rejected because the callback expects the wrong parameter type:

1type NumberHandler = (value: number) => void;
2
3function execute(handler: NumberHandler): void {
4  handler(42);
5}
6
7execute((value: string) => {
8  console.log(value);
9});

That is the core value of strong typing here: mistakes are caught before runtime.

Generic Callback Parameters

When the callback type depends on another type parameter, generics are the right tool:

1function mapItems<T, U>(items: T[], mapper: (item: T) => U): U[] {
2  return items.map(mapper);
3}
4
5const lengths = mapItems(["go", "rust", "swift"], (word) => word.length);
6console.log(lengths);

Now the callback stays strongly typed relative to the array element type and the produced result type.

Function Types with Objects

Strongly typed callbacks become even more useful when passing richer objects:

1type User = {
2  id: number;
3  name: string;
4};
5
6function withUser(callback: (user: User) => string): string {
7  return callback({ id: 1, name: "Ada" });
8}
9
10const label = withUser((user) => `${user.id}:${user.name}`);
11console.log(label);

This gives autocomplete, compile-time checks, and safer refactoring.

It also makes higher-order utilities much easier to use because the caller sees the exact callback contract instead of guessing from documentation alone. That is especially helpful in editor tooling, where parameter names and return shapes become visible immediately. It improves refactoring confidence too.

Interfaces Also Work

If you prefer interfaces, function signatures can be expressed that way too:

1interface Comparator {
2  (left: number, right: number): number;
3}
4
5function sortWith(values: number[], compare: Comparator): number[] {
6  return [...values].sort(compare);
7}

In modern TypeScript, type aliases are often simpler for plain function signatures, but both are valid.

Common Pitfalls

The biggest mistake is typing the callback too loosely, such as using Function or any. That throws away most of the safety TypeScript can provide.

Another mistake is forgetting that return types matter too. If the callback must produce a result, include that in the signature so the caller cannot silently return the wrong thing.

A third issue is overcomplicating the API when a named type alias would make the contract clearer. Inline signatures are fine for short cases, but long callback shapes deserve a reusable name.

Summary

• TypeScript fully supports strongly typed functions as parameters.
• Use inline function signatures for simple cases.
• Use type aliases or interfaces when the same callback shape is reused.
• Generics let callback types stay aligned with surrounding data types.
• Avoid Function and any if you want real type safety.