But I Have Promises to Keep

and script to write before I sleep

You may not know, but you likely just made a promise right now viewing this web page. Promises are powerful tools that arrived with the release of the ECMAScript 6 update (aka ES6), and they can save a lot of headache when dealing with asynchronous requests. I will give you a brief overview on the problem and how promises solves it.

The Problem

Javascript is a single threaded language, meaning that it processes tasks in order, one at a time. Code bits cannot run simultaneously. Say you had a web page with two buttons. One initiates a giant, tedious, recursive call that renders images on the screen and takes seconds to complete. The other logs ‘hello world’ to the console. If you click the first button and then click the second, the console log will not appear until the first button completes its actions.

You might use some asynchronous code to help circumvent this. When loading a web page, for example, you can use AJAX requests to render some elements onto the page before others, so that the user can use the website while other parts load. If you’re not comfortable with asynchronicity ,you can read more about it here.

But what if one of your functions depended on something retrieved asynchronously? You don’t know exactly how long the request might take.

Imagine Function A is loading an image asynchronously and Function B attempts to reference Function A; a reference error would be thrown because Function A hasn’t returned anything yet. You’d need a way to ensure that B doesn’t execute until A had.

Things might get even more complicated if Function D relied on the output of A, B, and another asynchronous Function C. And then something else relied on D. And so on, forever.

You can handle this by passing in functions as callbacks, with one to execute on success and one for failure.

doSomething(parameter, successCallback, failureCallback)

But what if you had many asynchronous calls? You might end up with some nasty code:

“The Pyramid of Doom.” Each function takes a callback that will be executed on success and a callback to be executed on failure. This ensure that no errors are thrown, because something will always be returned. But at what cost?

Enter the promise!

ES6’s promise object allows us to chain functions together in an elegant way while ensuring that the timing of those functions is appropriate.

Very similar to the above, but notice .then()

When using a promise, doSomething won’t be called until the Javascript event loop completes its current run; when the interpreter gets to the promise, the asynchronous method returns a promise to supply the value at some point in the future and the interpreter continues on.

Below, once doSomething completes, doSomethingElse will be invoked if it was successful and failureCallback will be invoked otherwise. Then, if doSomethingElse was successful, doThirdThing will execute. In this way, you can think of promises as if….then chains but for asynchronous requests. The benefit of promises is that they are chainable and easy to use. Here, all the failures would run the same function, failureCallback, but you could certainly have each function have its own unique function to run if failure is encountered.

You can even do things after a failure is encountered by chaining .then() after your .catch().

This will log ‘Initial’, then an error will be thrown and so the reader would move down to the catch statement and log ‘Do that’, and then it would log “Do this, no matter what happened before’

An important thing to note during chaining is that each function in the chain does require the previous function to return something in order to be triggered.

I hope you can see how powerful promises are now! They allow us to deal with issues that arise from asynchronous functions in a more intuitive way. Check out MDN’s webpage to see other things you can do with promises, like overriding Javascript’s default behavior when an error is encountered.