DEV Community

Pro tip: using Promise.then for function composition

Shalvah on June 26, 2018

I've become a fan of functional programming in recent times (even though I still don't know much about it). Over time, I've developed a habit when ...

Read full post

Johnny Reina • Jun 26 '18

The cool thing about Promises is that the then method, when used this way, is just like the map function. It has the same abstract type signature. This makes Promises behave like any other functor, which means that this method respects composition. Therefore,

somePromise
  .then(f)
  .then(g)
  .then(h);

is the same thing as

const w = pipe(f, g, h);
somePromise.then(w);

John Hardy • Jun 27 '18

Yes, I was thinking that as well. When chaining a sequence of maps, it's better to only map once using a composition of functions.

Shalvah • Jun 27 '18

I'm curious as to why you think it's better to "map once". I personally prefer using "then" repeatedly, because it might take a while for people who aren't familiar with functional programming to grab the concept of piping.

Angel Daniel Munoz Gonzalez • Jun 27 '18 • Edited

YES! I wish more people started to use similar patterns to this usage, but I still see a lot of deferreds and new Promise() for standard promise usage
Quite a good read Shalvah A!

as a side note:

I remember finally looking at the light with promises after reading several articles, but the one which clicked on me was this

pouchdb.com/2015/05/18/we-have-a-p...

In it includes one example of your usage, which in turn is part of a quiz in promises, ultra recommended lecture if someone doesn't understand promises

Daniel Levy • Sep 21 '18

@shalvah this article is fantastic! I've been exploring the ergonomics of the pattern (particularly around promises) for a little while now... I wrote up an example-rich github project to outline the refactor process: github.com/justsml/escape-from-cal...

@Angel, that pouchdb article is amazing, I make all my students read it :D

J. Pichardo • Jun 26 '18

The only issue I see here is that promise is always asynchronous and using then for function chaining might compromise shared data.

Shalvah • Jun 26 '18

I'm not sure I understand you. Could you give an example of what you mean by "compromising shared data"?

J. Pichardo • Jun 28 '18

I mean that each time you chain a function using then that function is added to the queue which means that it will wait for at least a tick to be called, my only concern is if during that tick a variable, that one of the callbacks relies on, is modified. Maybe is not a pressing matter, just a concern I have.

Nice post tho.

Daniel Levy • Sep 21 '18

@Pichardo Promises resolve only once, and their value is immutable. And in a functional promise chains each step results in a read-only state.

Adrian B.G. • Jun 26 '18

I've done a couple of functions like this, but still I haven't solved the problems of

testing it
how do you find out where exactly crashed on production and with what input?

Shalvah • Jun 26 '18

Testing: I don't think this is particularly a problem. You test them the way you test regular functions. Write unit tests for the individual functions and write a test for the entire pipeline.
Error handling: You can intersperse a couple of .catch blocks in there to handle specific errors during execution. But the problem would be when you need to exit the chain if an error occurs midway through. In such a case, I don't recommend using this approach, as that would lead to a lot of crazyyyy code. For uncaught errors, the stack trace would typically contain the name of the function that failed.

I hope I've addressed your concerns. Did I miss something?

Ashinze Ekene • Jun 26 '18 • Edited

It's called tacit programming or point free. I love doing it too

Shalvah • Jun 26 '18

Right. I recall seeing that in a book on FP. Limiting the number of points.