为什么将 flatMap 与异步 function 一起使用不返回展平数组？

Question

I want to understand why using .flatMap() with async does not return a flatten array.

For example, for Typescript, this returns an array of numbers: I know Promisse.all and async are useless with a simple array of number, it is just easier for reproduction

const numbers = [[1], [2], [3]];
// typed as number[]
const numbersFlatten = await Promise.all(
    numbers.flatMap((number) => number),
);

When this, for Typescript, returns an array of array of numbers (just added an async):

const numbers = [[1], [2], [3]];
// typed as number[][]
const numbersFlatten = await Promise.all(
    numbers.flatMap(async (number) => number),
);

Answer 1

All async functions implicitly return Promises. By making your .flatMap() callback async , it now returns a Promise that resolves to the number array. For .flatMap() to work correctly and for it to flatten its results, the callback should return an array, not a Promise:

 (async () => { const numbers = [[1], [2], [3]]; const numbersFlatten = await Promise.all( numbers.flatMap(async (number) => number), // same as `.flatMap(number => Promise.resolve(number))`, flatMap doesn't know how to flatten `Promise<number>` into a resulting array ); console.log(numbersFlatten); })();

Instead, you can use a regular .map() call to obtain a nested array of resolved values followed by a .flat() call:

 (async () => { const numbers = [[1], [2], [3]]; const numbersFlatten = (await Promise.all( numbers.map(async (number) => number) )).flat() // flatten the resolved values console.log(numbersFlatten); })();

Answer 2

I wanted to add that the fact Promise is eager also has performance implications.

const asyncFlatMap = <A, B>(arr: A[], f: (a: A) => Promise<B>) =>
    Promise.all(arr.map(f)).then(arr => arr.flat());

asyncFlatMap([[1], [2], [3]], async nums => nums); // Promise<number[]>

You can see in the code above that we need to map , then flat , with this additional round trip through the microtasks queue because of the then in-between. Doing this kind of round trip for the sake of playing Lego is wasteful.

Note that if you don't write an asyncFlatMap helper you can avoid that then of course. I'm making a general statement here.

If you happen to nest promises a lot you may be interested in Fluture .

Futures are lazy, so you can play Lego with them before anything is run.

import { resolve, parallel, promise, map } from 'fluture';
import { pipe } from 'fp-ts/function';

const numbersFlatten = await pipe(
    numbers.map(nums => resolve(nums)), // Future<number[]>[]
    parallel(10), // Future<number[][]>
    map(x => x.flat()), // Future<number[]>
    promise // Promise<number[]>
);

In the code above I converted the Future back to a Promise with promise in order to match your use case. It is only when this function is called that the computation is run. fork would also run the computation without ever involving promises.

In case you are not familiar with pipe : the first argument is the value which is threaded through the remaining function arguments.

The magic value 10 in parallel is just the maximum number of computations to run concurrently. It could have been anything else.