4 ms·

Some JavaScript people have been hostile to functional concepts since the beginning. See the missed opportunity to make Promise a monad.[1] [1] https://github.

• Waterluvian 5y ago
  I’m curious if someone can sell me, practically, in relatively few words, what that would gain us compared to Promises today. That link wasn’t sufficient to teach me. I’m a bit dense. :(
  • hajile 5y ago
    Basically, the current promises take a shortcut. If your promise returns a promise, the two promises are automagically combined into one promise. foo .then(() => returnsAnotherPromise()) .then(() => { /*only receives the nested promise*/}) The correct solution would not automatically flatmap foo .then(() => returnsAnotherPromise()) .then(innerPromise => { innerPromise.then(() = {}) //now we have access to the nested promise }) The second API is easier to statically type (creating a type that automatically, but conditionally removes a type is not necessarily0 easy). The second API makes some abstractions easier. The second API more intutitive for most people new to promises (I've seen it done a lot -- especially a few years ago). The second API allows you to interface with other monads without constantly having to do a special conversion any time you touch a promise. The current API is way more ergonomic for most current developers. In any case, it seems like there should a way to create your own proper monad promises along with an interface to normal promises when needed.
    • Waterluvian 5y ago
      I’m surprised to discover that promise flattening. Never noticed it before. Thanks!