All (or just most) of what you need to know about handling Promises

Ori Volfovitch on October 06, 2019

I Don't use Promises on a daily basis. But when I do, all I need is a simple usage example of how to handle them. What I find instead are over comp... [Read Full]
markdown guide
 

What's the reason to have promise hell in the first example when you can just chain promises one after another?

longPromise()
    .then((data)=>{
        console.log(data); // logs: longPromise resolved
        return shortPromise();
    .then((data)=>{
        console.log(data) // logs: shortPromise resolved
    })
});
 

Not sure what you mean.
You just removed the .catch(), which means you do not handle in case of rejection.

 

You can chain the Promises. Inside of .then(), you can return another promise and it'll let you add another .then() underneath. You add a single .catch() at very end, which will work for all the .then() chains.

longPromise()
    .then((data)=>{
        console.log(data); // logs: longPromise resolved
        return shortPromise();
    .then((data)=>{
        console.log(data) // logs: shortPromise resolved
    })
    .catch((error)=> {
         console.log(error);
    })
});
 

Yeah, as Joel mentioned, you can return promises to get one flat promise chain.
Imagine that you have 4 promises. If you follow example 1 in your post, you'll get promise structure like callback hell, but if you return next promise in every then, you'll get nice and flat promise chain.

Oh, now I understand.
Wow, this is worth editing the original post!

Thanks!

Another improvement you can make is not using anonymous function
It gives you testability and readability
So instead of:

longPromise()
.then((data)=>{
console.log(data); // logs: longPromise resolved
return shortPromise();
.then((data)=>{
console.log(data) // logs: shortPromise resolved
})
.catch((error)=> {
console.log(error);
})
});

you can do:
async function firstHandler(data){
console.log(data)
return shortPromise()
}

longPromise.then(firstHandler).then(console.log).catch(console.log)

But wouldn't this example start to get ugly if you had more that just 2 Promises?

getData()
.then(processData)
.then(convertData)
.then(saveData)
.then(notifyOnSuccess)
.catch(handleError)

looks ok to me
any how I'd go with async await today as much as I can, only use native promises if I need to wrap a callback from a library or something like that

Nice combo.
So you are actually chaining them asynchronously?

what do you mean?
you can't processData before you got the data, so it has to be done in series
getData() has to return a promise, the rest of the functions would automatically be converted to async

So why in your firstHandler example did you made the function to be async?

Optional.
If you use it elsewhere, and it is async, mark it as async.
only when I use anonymous function directly in the chain I won't mark methods with async unless I have to.

 

Hey Ori,
Looks good,
I'd add a few 'Gotchas' and maybe some more information here!

  1. When using async/await it's very difficult to use finally and catch, async await only deals with 'resolve'

  2. Promises are a great way (and I think the only way) to add a micro task into the event loop, micro tasks are the only way to ensure execution before the next tick. (done with Promise.resolve())

  3. You could probably await a Promise.all() as well, as it returns a promise

Other than that, good stuff!

 
code of conduct - report abuse