TypeScript doesn't have a way to express the higher-order types needed to give reduce() or forEach() call signatures that allow you to chain functions together like this safely. Neither can you do this with a for loop. Unless you actually unroll the loop and call arr[2](arr[1](arr[0]())), you cannot implement this sort of thing hand have the compiler catch you if you make a mistake. The implementation will therefore involve some amount of assertions where you just tell the compiler that what you're doing is okay.
That being said, if you want to have a reusable callChain() function which takes an array of "properly chained functions" as input, you can give that function a call signature which checks the "properness" (propriety?) of the array and which returns the right type. The implementation will be somewhat unsafe, but you only need to write that implementation once, and hopefully call it more than once.
Here's one possible way to do that:
type TupleToArgs<T extends any[]> =
Extract<[[], ...{ [I in keyof T]: [arg: T[I]] }], Record<keyof T, any>>;
type TupleToChain<T extends any[]> =
{ [I in keyof T]: (...args: Extract<TupleToArgs<T>[I], any[]>) => T[I] };
type Last<T extends any[]> =
T extends [...infer _, infer L] ? L : never;
function callChain<T extends any[]>(fns: [...TupleToChain<T>]): Last<T>
function callChain(funcs: ((...args: any) => any)[]) {
const [f0, ...fs] = funcs;
return fs.reduce((a, f) => f(a), f0());
}
Before I go into how it works, let's make sure that it works, using your examples:
const result = callChain(arrayOfFunctions)
// const result: [number, number]
console.log(result) // [1, 1]
callChain([a, b, b]) // error!
// ------------> ~
// Type 'B' is not assignable to type '(arg: number) => number'.
// Types of parameters 'str' and 'arg' are incompatible.
// Type 'number' is not assignable to type 'string'.
That's what you want. The proper chain is accepted and the return type is [number, number]. And the improper chain results in a compiler error where the first bad element in the chain is highlighted as taking the wrong input type.
So, that's good.
So, let's explain how it works. First, the function itself:
function callChain<T extends any[]>(fns: [...TupleToChain<T>]): Last<T>
function callChain(funcs: ((...args: any) => any)[]) {
const [f0, ...fs] = funcs;
return fs.reduce((a, f) => f(a), f0());
}
The call signature is generic in T, a tuple type corresponding to the return type of each function in the chain. So if T is [string, number, boolean], that means the first function in the chain returns a string, the second returns a number, and the third returns a boolean. The TupleToChain<T> type should therefore turn such a tuple of types into a tuple of functions of the right type. The return type of callChain is Last<T>, which should hopefully be just the last element of the T tuple.
The function is written as a single-call-signature overloaded function. Overloaded function implementations are intentionally checked more loosely by TypeScript, (see ms/TS#13235 for why this is), which makes it easier to split apart the function into the strongly-typed call side and the weakly-typed implementation. The implementation uses a lot of the any type to sidestep compiler errors. As I said at the outset, the implementation can't really be properly type checked, so I'm using any to stop the compiler from even trying.
At runtime we're splitting the array into the first element (which takes no input) and the rest of the array (which all take an input), and then using the reduce() array method to do the actual chaining.
Let's look at the types, now. The easy one is Last:
type Last<T extends any[]> =
T extends [...infer _, infer L] ? L : never;
That's just using variadic tuple types and conditional type inference to pluck the last element from a tuple.
Now for TupleToChain:
type TupleToChain<T extends any[]> =
{ [I in keyof T]: (...args: Extract<TupleToArgs<T>[I], any[]>) => T[I] };
This is just a mapped tuple type which takes the bare types in T and produces a new tuple of functions. For each type at index I in the input tuple T, the function in the output tuple will return the type T[I], and it will take as a list of arguments something called TupleToArgs<T>[I]. So TupleToArgs<T>[I] had better give us the list of arguments required for the Ith function in the chain. If I is 0, then we want an empty list like [], whereas if I is J+1 for some J, then we want a list with the single element [T[J]]. (This will be an array type no matter what, but the compiler can't see it here, since TS4.7, so I wrapped it with Extract<..., any[]> to convince the compiler of this fact.)
To be painfully clear, if T is [string, number, boolean], we want TupleToArgs<T>[0] to be [] in order to form ()=>string; we want TupleToArgs<T>[1] to be [string] in order to form (arg: string)=>number; and we want TupleToArgs<T>[2] to be [number] in order to form (arg: number)=>boolean.
So here's TupleToArgs:
type TupleToArgs<T extends any[]> =
Extract<[[], ...{ [I in keyof T]: [arg: T[I]] }], Record<keyof T, any>>;
This is another mapped tuple type where we wrap each element of T in a one-tuple (so [string, number, boolean] becomes [[string],[number],[boolean]]) and then we prepend an empty tuple to it (so we get [[],[string],[number],[boolean]]). This indeed works exactly how we want TupleToArgs to work (the extra [boolean] at the end doesn't hurt anything)...
...but we wrap it in an extra bit Extract<..., Record<keyof T, any>> using the Extract<T, U> utility type. This doesn't actually change the type, since the returned tuple will indeed be assignable to Record<keyof T, any>. But it helps the compiler see that for I in keyof T, the type TupleToArgs<T>[I] is valid. Otherwise the compiler gets confused and is worried that maybe I is not a key of TupleToArgs<T>.
And that's basically it. It's kind of convoluted, but not the worst thing I've ever written. I'm sure there are edge cases where it doesn't work. Certainly if your array of functions isn't defined as a tuple type you'll have a bad time. For a single chain like [a, b, c], there's really nothing better than just c(b(a())). But if you find yourself needing to write such chains many times, something like callChain() be worth its complexity. Exactly where the line where that happens is subjective; in my opinion you'd have to be doing these tuple-typed function chains quite often in your code base for it to be worthwhile. But whether or not you actually use this, it's interesting to consider how close the language can get you to representing such operations in the type system.
Playground link to code
