Promises
Javascript is a synchronous, single-threaded language, that is to say that it doesn’t allow for multiple commands to run at the same time. Ruby is the same in this regard but the order of execution is exactly as it has been written in the program. In JavaScript, this is not always the case. As we have seen, this can be quite limiting, and so we use callbacks to be able to write Javascript asynchronously. We’ve already looked at callbacks, but just to refresh quickly callbacks are simply functions passed as parameters. This is particularly important when doing anything that requires waiting (e.g. some kind of user input, stuff loading). A promise is tool to help us write callbacks more concisely, and avoid what is sometimes referred to as callback hell. Promises were introduced in ES6 but versions have existed in various frameworks for a while (Q, RSVP.js etc.)
A promise represents a value that may or may not become available in the future (or that might be available already). In the UK, universities make offers based on students’ expected A-level results, since offers are made before exams are sat. They might agree to take a student if she gets, say, at least two ‘A’s and a ‘B’. If the student makes the offer, then she gets accepted. If she doesn’t, then she won’t. Promises work in a similar way.
A promise is an object that represents an operation that hasn’t finished yet, but is expected to (in the past, promises were known as futures). It has three states: pending, fulfilled, rejected. When the promise is first created, it’s in the pending state. It will then change to either fulfilled or rejected. At that point it becomes settled, and will stay in this state permanently.
Promises are a good tool to have because they enable us to make our code more “composable” when used correctly. Broadly speaking, composability means evolving more complex functions (higher-order functions) from simpler ones (perhaps involving several layers), which is good because it makes our code more DRY.
More complex callback structures without promises can often turn into complex, deeply nested structure that are hard to read and also to debug. One way we can avoid this is by abstracting out the callbacks into their own functions. Another way we can refine our code by using promises.
Basic Syntax
The .then and .catch Methods
The .catch and .then methods are built into promises and called automatically on success or failure of the promise.
Going back to our earlier example, the student getting three ‘A*’s (i.e. success), would result in the promise’s success callback of the .then method being called. The .then method takes callback functions for both success and failure of the promise. Both of these are optional. The student failing all her exams and receiving no A-levels (i.e. rejection), would result in the .catch method being called. The .catch method gets called with a callback function to deal with the error and has one argument (reason). Remember that rejections happen when a promise is explicitly rejected, but can also happen implicitly if an error is thrown in the constructor callback.
Promises in Action
This is much harder to read than the example with only one image, and is also not running in parallel — each loadImageCallbacked function must wait for the one before it to load.
This is much cleaner than the callbacks example with multiple images, and has a flat structure (not a pyramid). It also allows us to only handle errors once, because we are chaining the .then and .catch methods. This chaining is known as composition.
The .all() method was introduced in ES6. It takes an array of promise objects, and waits for all the promises to settle before it moves on to the .then method (if applicable).
A nifty little tool: http://stuk.github.io/promise-me/
