DEV Community

Discussion on: Promise Chains are Kinda Awesome

Collapse
bennypowers profile image
Benny Powers 🇮🇱🇨🇦 Author

Hi Dustin!

I'm not sure what you mean specifically here when you use the words "implicit" and "explicit" here. Re-reading your insights, I can't tell whether or not you just mean "good" and "bad" or "my style" vs "not my style". Can you be a drop more explicit (badum-ching!) and provide an example of how you would rather do this?

WRT the closures, counting parens is definitely a chore. One better suited to IDEs and linters, which I consider pre-requisites. Even with all that, though, closure isn't the only option here. As mentioned above, the sharp refactorer might prefer to pass POJOs or more sophisticated ADTs to handle all that state.

Thanks for dropping by :D

Collapse
kosich profile image
Kostia Palchyk • Edited on

Well, I agree with Dustin that without some context highlighting IDE it's hard to argue what's happening down that .then chain. (I probably would start with re-indenting such code if I saw it in a codebase)

And async operations are already tough to understand. (Probably that's why some people invented async/await)

So, IMHO, it's a cool approach with all those curried functions, really!

Though in real code (if I had friends to invite) I'd use more declarative way, e.g.:

// parallel
all(
  groceries()
    .then(a)
    .then(b)
  ,
  friends()
    .then(c)
    .then(d)
)
// and then combined
.then(results => {
   // ...
})

there are some libraries actually that have parallel/sequential helpers to get rid of those .then chains, though I haven't found any quickly enough

It's a bit more like a callback hell, I know, yet for me personally this way its easier to understand the sequences and dependencies.

Again, it's a personal opinion. Still, it was interesting for me to read those point-free (?) functions. So thanks, Benny!

P.S. Maybe, the lesson here is that we should mix those approaches.