JavaScript Promises Discussion: Make Them Monadic? (2013)

Promise.all() does a pretty good job of parallelizing tasks while maintaining readability.

I'm not sure how it works in all languages, but in Python you have to deal with errors in a try/except block. In general the way you handle errors that happen on "blocking" async calls is by wrapping in a try-catch style syntax and handle the error. How would you handle the error otherwise?

You can handle asynchronous code in JS in four ways: callbacks, Promises, generators, and async/await. In the former two, errors are dealt with in a non try-catch way, to the programmer, because either you pass the error as the first callback parameter, or the VM handles error passing for you and you deal with it in a catch block. The latter two you must wrap code that may fail in a try-catch block (or just not handle the exception). You can stick with callbacks, but it's generally easier to read well written Promises, and in a lot of cases async/await make it even clearer. The only time that it can be confusing or difficult is if you want to do multiple await calls simultaneously.

This is one of the better javascript FP books that ramps into fairly advanced concepts: https://mostly-adequate.gitbooks.io/mostly-adequate-guide/

A simpler, gentler introduction is available from https://www.manning.com/books/functional-programming-in-java...

> At a glance it just feels super complex, academic

Agreed, because unfortunately, it is. (I might substitute "complex" with "hard" -- the ideas are actually very simple; understanding the big picture of how they fit together is hard)

> It's not at all clear why I should be thinking about my JavaScript algebraically at all times, or what the practical advantages are.

The main goal is to be able to write more and more code as pure functions -- this is hopefully an accepted best practice: functions with minimal inputs and no tangle of global state/context are far easier to reason about, test, and with proper data design, reuse.

But you quickly run into an issue: how can I write pure, stateless functions when dealing with inherently stateful surroundings (IO, DOM, database, etc.). That's what all this category theory jargon is about.

I am surprised to see so much venom against Promises expressed here. I am young, but I began coding (as a profession) just when Angular 1 was popular and I remember callback hell was a real thing.

A few years later, I use Promises a lot, and they work really well. The way errors bubble is logical and easily controlled, it's almost impossible to throw an unhandled promise exception, doing 'parallel' tasks is easy with ```Promise.all([])```, and there's pretty limited complexity with the way a Promise always returns a Promise.

I find the simplest way to use them is to define a class that has a few data properties you'd like to track.

  class Handler {
    constructor() {
      // shared variables can be set / reset here
      this.defineInitialState();
    }

    executeAction() {
      return (
        this.promiseFn()
        .then(() => this.anotherPromise())
        .then((passedArgument) => this.promiseExpectingArgument())
        .then(
          // success case
          () => this.successHandler(),
          (err) => this.errorHandler()
        )
      );
    }
  }

It's modular and you know what to expect (it's always a promise!). Sure, it's imperfect, but I think its weakly opinionated simplicity is a good tradeoff. After all, it makes no distinction of whether any of the functions in that chain were synchronous or not, and that's a nice thing to know. It also makes testing with dummy sync functions in place of actually asynchronous ones a 0-effort integration.

I don't know about this async / await keyword stuff, and if you have to wrap it in a try/catch block, that's unfortunate but also seems like it's not the end of the world. After all, isn't the Go language constantly requiring you to say "if err != nil "? Explicit error handling isn't even a bad thing.

Anyways, this is just my opinion, it's fair to have your own, and maybe other languages handle asynchronicity more gracefully, but from what I've seen this is a clean way to wrap async OR sync code in a context that makes it always behave predictably and readably.

Async/await is the do-notation for Promises and generators can be re-purposed as do-notation for any other monad, see e.g. https://curiosity-driven.org/monads-in-javascript#do