Folding Promises in JavaScript(codementor.io) |
Folding Promises in JavaScript(codementor.io) |
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:
const listOfPromises = [...]
const result = Promise.all(listOfPromises).then(results => {
return results.reduce((acc, next) => acc + next)
})
?> 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.
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')
Or: How to make simple things complex and make a codebase a complete puzzle for those that come after you?
I don't think you need to necessarily memorize these transformation names, but writing these types of functions is all I seem to be doing these days, transforming one thing into another line for line.
pullAllBy(pluck(things, 'bar').map(compose(xor, lol, rofl)).reduce(differenceWith('id'))
Complaining about learning them is like complaining about for loops. They just exist.
Just because some are more familiar with for loops than map doesn't mean that more universal, immutable, expression - based solutions are not widely familiar and easy to understand to programmers coming from other languages.
Readability is subjective.
It is indeed very unfortunate that the article conflates terminology.
So a function that turns an array into another array of different length would be endomorphic (since it maintains the same type), but not homomorphic since it has a different structure (a different set of keys).
const reduceP = async (fn, identity, listP) => {
const values = await Promise.all(listP)
return values.reduce(fn, identity)
}
let total = 0
while (listP.length > 0) {
total += await listP.pop()
}In any case, this is very helpful, thanks for writing/sharing.
As long as you know what the transformation is, you can convert between them without data loss.
You're right, because for a pair of functions f and g, you have an isomorphism if:
f(g(x)) == x
g(f(x)) == x
(([a]) => {a})( (({ a }) => [a])({ key: 'data'}) )
{ a: 'data' }
forall x. objToArray(arrayToObj(x)) == x
forall x. arrayToObj(objToArray(x)) == x const objToArray = Object.entries
const arrayToObj = (a) => a.reduce((a, [k, v]) => ((a[k]=v), a), {})
arrayToObj(objToArray({ foo: 'bar' })) // { foo: 'bar' } listOfPromises.reduce(
async (m, n) => await m + await n,
0,
)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.
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.
https://ncatlab.org/nlab/show/endomorphism
I think "endomorphism is a homomorphism ..." is more common, but notably is not the usage in Haskell (https://hackage.haskell.org/package/base/docs/Data-Monoid.ht...)
If you don't use the builtin transformations, you'll just end up re-implementing them, poorly. And adding to the cognitive overhead with new concepts. And I have to read your code with a fine-toothed comb to ensure it's really side-effect free. I don't advocate turning everything into a named function as in your example though, short one-off functions should all be inline IMO.
Ideally this is how it should be written for maximum readability.
things
|> pluck('bar')
|> map(xor)
|> map(lol)
|> map(rofl)
|> reduce(differenceWith('id')
Here is it using lodash (not even lodash-fp), and this is going to do a single for loop when executing because this is lazy.
_.chain(things)
.pluck('bar')
.map(_.xor)
.map(_.lol)
.map(_.rofl)
.reduce(_.differenceWith('id'))
.value();
things
|> pluck('bar')
|> map(compose(rofl, lol, xor))
|> reduce(differenceWith('id')Composing xor, rofl, lol isn't any better (esp in terms of readability) than it is individual maps.
What would be better is this:
const makeHilarious = compose(rofl, lol, xor);
things
|> pluck('bar')
|> map(makeHilarious)
|> reduce(differenceWith('id')so someone reading over it can kind of skim down the left side and follow what's happening and scan to the right if they need to understand some part in detail
things
.map(thing => x.bar)
.map(thing => {
// whatever happens in rofl
// whatever happens in lol
})
.reduce((acc, thing) => {
// more stuff
}, {})
It is one thing to quickly be able to understand that the person is doing a xor, then a rofl and then a lol of each element of an array, and a whole another thing to understand what the combination of these three actions over an array means. The python school of "code is read more than it's written" heavily stresses on explaining how easily the code should be understandable the first time someone reads it, but not whether it's easy to reason about or not.
The beauty of declarative style programming isn't to get more readable code immediately, but rather that once you understand the vocabulary, how easy it is for you to understand and reason about the code.
For instance, imagine reading a novel which is written like this:
"After Jack was done from the place where he went to do things for money everyday, he entered an establishment which served drinks that get you inebriated for money. This establishment was one he frequented regularly and preferred it over the others. He asked the man behind the counter for a wheat fermented brewed drink. After putting the drink to his lips and pouring it in to his mouth, he felt a sense of calmness enter his mind. It pushed all the thoughts which occupied his mind away, as he earlier desired before entering this establishment."
As opposed to:
"Jack really needed a drink after hard day at work. He went to his favorite pub, and ordered his favorite beer. After finishing the pint, he finally felt relaxed."
The Python philosophy (which is permeated everywhere in imperative world) is to describe everything in the simplest possible terms just in case there are people who may not understand what work, pub, beer, bartender, and relaxed means. But this just prevents from understanding of the actual purpose of the code.
This is at least the basic philosophy behind not using for loops everywhere.