> Promise.reduce will start calling the reducer as soon as possible, this is why you might want to use it over Promise.all (which awaits for the entire array before you can call Array#reduce on it).
Whether this is ever necessary is another matter :)
let accumulator = 0
for (let item of array) {
const value = await item
// your code here
}
This way you could have the same reducer handle the results and begin updating the UI as the results come in.
An example real-world app might be a price comparison tool or social media aggregator.
But it's still a serialized operation so the parallelism is still limited. What's really needed is a "parallel reduce" using something like C's select function that will reduce in an arbitrary order using any promises that are ready at any given step.
Your example code works just fine for promises of course, but not all monads support a coalescing operation like Promise.all.
So even though this article only discusses folding over Promises, the core idea here can be generalised to any monad type (such as Promise, Result, Option, or anything else)
Actually, they do. Haskell calls it sequence :: (Traversable t, Monad m) => t (m a) -> m (t a) [1]
It works by consuming the structure outside the monad and rebuilding it inside. A possible implementation specialized for lists is
sequence [] = return []
sequence (h:t) = do
h' <- h
t' <- sequence t
return (h':t')
Promise.all is not just sequence though, there's some additional subtleties to it. In particular the fail-fast behaviour:
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
That's the kind of fundamental coalescing operation that you cannot implement with bind on plain monads.
I challenge the view that making the identity value being able to be something other than a Promise is 'making it better'. Pointless abstraction is one of my pet peeves in this industry. This looks like it has gone from a fairly straightforward, if kludgy, piece of code to something far more complex. Why not just: