Add flatMap (also known as concatMap, mapcat, mapcons, ...)

Often times I find myself returning an array of array of promises, and flattening it myself with a finishing reduce. A contrived example:

getJSON('products.json')
// we receive an array of articles:
// [{}, {}, {}]
    .then(articles => articles.map(getRecommendations))
// for each article, we receive an array of recommendations:
// [[{}, {}], [{}], [{}]]
// but we want it as a single array, so we need to concat them
    .reduce(ret, recommends => ret.concat(recommends))
// we now have a flat array, yay!
// [{}, {}, {} ,{}]
    .map(recommendation => recommendation.date);

In collections-land that’s known as flatMap, mapcat, concatMap and so forth.

Is it useful enough to include in core, or niche and simple enough that flattening be left to the user?

[benjamingr]

My opinion is that we should stop adding array-related methods to core and start planning how to take the existing ones out (preferably into a companion Stream library 😃

99% of our users don’t care about how sound or how nice the theory or the types are. People care about usefulness.

In practice, map filter and other methods are seeing a ton of use in bluebird. Removing them would be a spit in the face of our users telling them that theoretical niceness trumps actual usefulness.

If abstract references (bind operator, or whatever @zenparsing is calling it today) make it in that changes my opinion since it would let us extend stuff from the outside.

[grantila]

Adding arbitrary array helpers for fun without actually solving problems regarding promises doesn’t make any sense at all.

Bluebird’s map, reduce and filter functions are not just nice array helpers. After all, we already have this in ES5. Bluebird’s versions work with arrays of promises and values mixed, as well as with operators (the function to map, filter and reduce) which might return promises. This logic is non-trivial, and the support in bluebird (or in a support library) makes perfect sense.

If this actually would respect promises in both levels - the outer and inner arrays - it could potentially be bluebird-material, but It would affect the interpretation of the concurrency option in non-obvious ways. In many situations you would like to have different weights to the concurrency of the outer and inner mapping jobs, and then all of a sudden it becomes a bit messy.