
Better Promises in JavaScript - franciscop
https://francisco.io/blog/better-promises/
======
mnr
This is already a feature in Vanilla.js [1] in the "Parentheses" module.

Example:

    
    
      const lines = (await fetch(myUrl)).text().split('\n');
    

[1] [http://vanilla-js.com/](http://vanilla-js.com/)

Edit: magic-promises promotes all accessed properties to magic-promises as
well, and performs magic on functions, so it's not exactly the same, but I'm
not sure if I'd want to add the proxy overhead to my code just to make my code
more "fluent".

~~~
zebracanevra
fetch's Response.text also returns a Promise, so you'd have to await twice:

    
    
      const lines = (await (await fetch(myUrl)).text()).split('\n');

~~~
mikewhy
I've always just added an overload:

    
    
        function fetchText(input?: string | Request, init?: RequestInit) {
          return fetch(input, init).then(x => x.text())
        }
    
        function fetchJson(input?: string | Request, init?: RequestInit) {
          return fetch(input, init).then(x => x.json())
        }

------
felixfbecker
I love it when articles just put statements out like "This syntax would be
much better, wouldn't it?" and then just assume the answer is obviously yes
and don't find the need to provide any arguments for that.

I disagree. Explicit is better than implicit.

~~~
franciscop
I agree, explicit is better than implicit. But redundant is worse than non-
redundant. This library just provides syntax sugar to make things cleaner.
There are many times that arbitrary decisions have been taken. Why cannot you
wait to an array of promises? Wouldn't that be explicit and clear?

~~~
monsieurbanana
Awaiting an array of promises looks neat, but it has a (small?) caveat: you
can't do the same for the non-await version. You can't do `[...].then()`.

I'm less fan of the second proposition. Imagine someone seeing that snippet on
internet and copying it: he would have no way of knowing that ".text()" is
actually a promise and could potentially be making more I/O calls than he
thought.

------
marcodave
It's lovely how node.js started with callback nesting hell, then to promise
chaining, then to async/await, then to "magic" libraries like this.

How long since someone will figure out how to get rid of the (error-prone)
await keyword, and go back full circle on plain old synchronous-style syntax?

~~~
woah
This library has some very minor syntax sugar. Async/await is currently the
most ergonomic abstraction for handling single-thread concurrency.

~~~
WorldMaker
Also, the examples here aren't as "unergonomic" as the article suggests with
async/await.

    
    
        const lines = await fetch(...).then(res => res.text()).then(res => res.split('\n'))
    

Any use of .then in async/await is a code smell.

The obvious single line refactor (as presented in other threads):

    
    
        const lines = (await (await fetch(url)).text()).split('\n')
    

But a clearer refactor is simply multiple lines to make each "step" clear as
mud:

    
    
        const response = await fetch(url)
        const text = await response.text()
        const lines = text.split('\n')
    

Yes, it's a bit over-verbose than the one liner, but ergonomically it is step-
by-step imperative programming just like Grandma C++ used to bake, and few
would argue that it isn't readable old-fashioned ergonomics.

Promise.all is a tougher thing to get "ergonomics" from, but more often than
not, a refactor to a "classic" for loop pattern is often clearer. The
semantics change, unfortunately, yet more often than not the clearer "one-
thing-at-a-time" of the simpler refactor is easier to debug, less harsh on
called services, less pressure on client memory, and simpler to progress
report.

Instead of:

const responses = await Promise.all(urls.map(url => fetch(url)) const texts =
await Promise.all(responses.map(response => response.text()) for (let text of
texts) { doSomething(text) }

Try:

    
    
        for (let url of urls) {
          const response = await fetch(url)
          const text = await response.text()
    
          doSomething(text)
    
        }
    
    

Again, the semantics change: instead of waiting for all of them to complete as
massively parallel it operates a bit more "synchronously" one at a time. But
the benefits again are that ergonomically it is much clearer what each
individual step is, how much work has been done, roughly how much work is left
to do. Additionally, you aren't creating a massive array of the text of every
response before operating on each text, which can be a big deal for
performance memory pressure. More often than not, I've seen cases where the
simpler for (let of)/await pattern here is more performant than all the
parallel calls simply because of the drop in this memory pressure.

For cases where you do need more of the parallelism, ESNext AsyncIterable is a
better plan than Promise.all(), and affords the for-await pattern:

    
    
        for await (let response of responsePromiseIterator) {
          const text = await response.text()
          doSomething(text)
        }
    

Which again, is more ergonomic overall, often easier to get the performance
right than Promise.all(), and easy enough to change to different parallel
strategies because the code stays the same regardless of the scheduler used to
build your async iterator.

------
Boulth
Very cool although I'm missing the explanation of how this is done. Are you
using Proxies like here: [https://curiosity-driven.org/monads-in-
javascript#chain](https://curiosity-driven.org/monads-in-javascript#chain) ?

~~~
franciscop
Exactly! The whole source code is basically Proxy() functions:
[https://github.com/franciscop/magic-
promises/blob/master/mag...](https://github.com/franciscop/magic-
promises/blob/master/magic.js#L81)

------
schindlabua
What Javascript really needs is monads and do-notation. Can I use Haskell on
the web yet?

~~~
girvo
Yeah, it’s called Purescript and it’s quite lovely. Give it a look!

~~~
Boulth
As much as I like PureScript (it's like a cleaned up Haskell!) it has some
issues, e.g. with performance (as it uses instanceof a lot).

There is also this minor thing that that the compiler is not written in
PureScript.

------
franciscop
Exploring the reasons why I launched a library to improve async-heavy
workflows which falls back to normal promises. It is very useful specially for
tool authors, see the library I also published recently `fs-array` using
`magic-promises`.

------
rhinoceraptor
Promises were a giant mistake. How many times have you had a programming error
(TypeError, ReferenceError, etc.) suppressed by your operational error
handling code?

------
everdimension
IIRC promises already have a `map` method which is synonymous to the `then`
method.

~~~
franciscop
Not with native promises. You have the Promise.all([...]), which is explained
in the article but no .map() AFAIK

------
lisq199
I think RxJS already solves the problem.

[https://github.com/ReactiveX/rxjs](https://github.com/ReactiveX/rxjs)

~~~
woah
Solves what problem? The article is about some very minor syntax sugar, while
you are plugging a tangentially related library with a whole raft of its own
abstractions. I’m struggling to understand the context here.

~~~
franciscop
Suggesting RxJS in this context IMO is like when someone suggests doing `const
$ = sel => [...document.querySelectorAll(sel)];` as helpful syntax sugar for
the 20-lines of JS project but they get shut down because it's no React.

