Javascript Promises Best Practices & Anti Patterns

The following might look like an opinionated article, please give your opinions as well. I am actually just publishing this to validate my thoughts. Do recommend if you agree with it.// After publishing this, I found another great blog post by Nolan Lawson. // Check it out here.// You can check that out and come back here for global error logging.

Improving a Piece of Bad Code

So lets start with bad code. This is an example of someone who hasn’t escaped callback Hell.

Here all the underlying function calls return Promises, so there is no need to create new Promise but rather use return directly:

Now because we can just pass the output of one function to another, we can just chain them like this:

Now because our functions are simple, we can even compact it down to this:

Simple and easy to understand isn’t it.

Multiple Variables

Now lets take an example of where you need two variables. Lets say for example you had a type of sausage and you need a particular type of bun for it. In this example we need the responses of two promises and one is dependent on another.

You can extract the inner function out to another function, but you will be creating your closure there, so its going to be one and the same thing.

There is another option of using Promise.all but I feel that makes the code difficult to maintain. But its a personal choice.

Error Handling

Now that we know how to chain promises, lets see some error handling. Can you differentiate between these two?

There is a very important difference between the above two examples, people who only recently have moved from jQuery to React/Redux Stack who would have started using Axios, Fetch or other similar libraries feel that React started eating up their errors rather than propagating them forward.

But its not React / Redux eating your errors.

Lets say for example you have a Runtime Error in the doSomething function above, in the requestA flow of things, your error would go into the catch and then fallbackForRequestFail would be called, when actually it should be fallbackForRuntimeError should be logged so that you are notified rather than it just mysteriously disappearing.

So in essence in the requestB flow of code, only function will be called amongst the two. And any other error like Runtime Error will be propagated ahead which you can handle individually or just log such errors to your error logging service and fix them on a case by case basis.

Log Unhandled Rejected Promises

In the Browser

In Node.js

You can read more about Handling Rejected Promises here.

Do comment if you feel I’ve made a mistake. Do recommend if you feel more people should know about this. Also check out Nolan Lawson’s in depth article here.

Hacker Noon is how hackers start their afternoons. We’re a part of the @AMIfamily. We are now accepting submissions and happy to discuss advertising &sponsorship opportunities.

To learn more, read our about page, like/message us on Facebook, or simply, tweet/DM @HackerNoon.

If you enjoyed this story, we recommend reading our latest tech stories and trending tech stories. Until next time, don’t take the realities of the world for granted!