DEV Community

Simplify JavaScript Promises

Sunny Singh on December 27, 2019

I love promises. Not from people, but from JavaScript. Tweet Quote I love promises. Not from people, but from JavaScript. Promises make your cod...

Read full post

Amin • Dec 27 '19

Hi Sunny, very interesting article. Thanks!

I especially loved this one-liner:

const data = await fetch('/api').then(res => res.json());

I think you can be even more concise and completely ditch the use of the promise.then method by using this example (inspired by yours, slightly modified so it can be easily tested):

"use strict";

async function main() {
    const api = "https://jsonplaceholder.typicode.com/users";
    const users = await (await fetch(api)).json();

    console.log(users);
}

main().catch(console.error);

This is using two await keyword, but with parenthesis to control the order of the await flow.

I also added a simple catch to handle errors (even if I'm not doing interesting stuff with it, yet).

What do you think of that? Is it better or worse? Let me know!

Sunny Singh • Dec 27 '19

Definitely more concise!

I think there is something to be said about how a .then reads a bit better, but this can be argued both ways. Either example takes advantage of the language to do one thing: fetch data.

In most scenarios, you would have a helper function anyway, which is essentially what you wrote (I would just rename it to something like fetchUsers()).

Will Adams • Dec 28 '19

Just wanted to add in that fetch doesn't throw errors or reject so .catch won't fire there. You need to throw your own errors with fetch.

Amin • Dec 28 '19

From the documentation, it is stated that

A fetch() promise only rejects when a network error is encountered

So I guess this is the case when the fetch method can throw an error.

Will Adams • Dec 28 '19 • Edited

Yeah you'll want to throw your own errors if you're using fetch and want to catch any errors. Something to be aware of otherwise most of your 'errors' will end up in your .then

dimitrispapadimitriou • Dec 27 '19

What do you think about this approach
medium.com/@dimpapadim3/asynchrono...

Amin • Dec 28 '19

I like it! Even if I personally think that this API could be sexier but I'm a big fan of FP and its concept (especially in Elm, Haskell or Rust).

K • Dec 27 '19 • Edited

Nice article, there needs to be more about promises because their error handling is a bit finnicky.

Always add a .catch(), because promises will swallow your errors without any second thought.

Also, remember to re-throw your error inside the .catch() handler if you only handle a specific type of error, because the other error types will also end up there and be swallowed as well.

Sunny Singh • Dec 27 '19

Are you sure that you always need to add a .catch()? As long as an error is thrown, and you don't swallow the error yourself inside of your own .catch(), then it should keep bubbling up until it reaches an error handler. I could be wrong but this is the behavior I'm used to seeing with async/await.

K • Dec 27 '19

I think you're right.

But if you deep down it can always be the case that there is a catch somewhere above that eats errors.

Sunny Singh • Dec 27 '19

Agree, it's generally a good idea to be explicit and prevent any edge cases.

SavagePixie • Dec 27 '19 • Edited

So, you're basically using the then and catch methods of a promise and then adding an await in front of it? Why not just handle the data with another then?

I mean, once you start writing code like this:

const data = await fetch('api/url')
    .then(res => res.json())
    .catch(handleError)
handleData(data)

You might as well put the handleData expression into its own then.

fetch('api/url')
    .then(res => res.json())
    .catch(handleError)
    .then(handleData)

Sunny Singh • Dec 27 '19 • Edited

It depends on the flow that you want in your code.

The benefit of async/await is not having to deal with callbacks and maintain what looks like a synchronous flow.

However, only using async/await has drawbacks, so that's where you might want to use
callbacks in .then() or .catch() to only handle some things like data transformation and error catching.

So you could handle your data with another .then(), and that's totally valid. Just depends on code style preference.

SavagePixie • Dec 27 '19

There are a couple of things that confuse me.

First, I guess I don't see what's the problem with callbacks. I mean, I know what people used to call callback hell and all that, but callbacks don't always generate it. In fact, functions as first class citizens is an amazing feature of JavaScript (map, filter and reduce being good examples of why). So I don't quite understand why not having to deal with callbacks would be a benefit.

Second is that you're already dealing with callbacks. You've got callbacks when you pass data through a then and when you handle errors. So I don't quite see what you're avoiding by using this method.

That's why I am a bit confused as to what you're supposed to be improving on. Mind you, I'm not saying that you're not getting anything out of it. I'm saying that I don't see what you're getting out of it that wouldn't be improved by ditching async/await altogether.

Bonus track: A lot of people do say that async/await makes your asynchronous code look synchronous. I find it an odd statement, though, as promise syntax looks a lot more like these synchronous snippets of code:

const transformNumbers = array => array
    .filter(isEven)
    .map(double)
    .map(addOne)
    .reduce(getMinMax, {
        min: Infinity,
        max: -Infinity
    })

const checkAdjacent = number => number 
    .toString()
    .split('')
    .some((x, i, a) => x == a[i - 1])

And more synchronous code would look like that if the TC39 guys finally implemented the pipeline operator.

What async/await does seem to do is to make asynchronous code look more imperative than promises. So maybe that's a thing you're getting by using your method?

Tanmay Naik • Dec 27 '19

This is very well explained. I honestly found Promises a bit confusing initially in terms of understanding what's happening in the code so I stuck to async/await to avoid complicating it for myself. This helped clear it up. Well probably start using them more now

Sunny Singh • Dec 27 '19

Super happy to hear that Tanmay! The async/await syntax actually helped me understand how a Promise works better, but it definitely took a long time.

Kevin • Dec 27 '19

This is actually the first useful example of promises I have seen. I am normally not a fan of them.

I am an old callback fan. Didn't begin to move past them until async/await.

Sunny Singh • Dec 27 '19

Thanks Kevin! I'm in the same boat, haven't really seen a huge value of Promises until async/await, but after still experiencing some headaches with them I realized there's some valid use cases in using both syntaxes.