Advanced Asynchronous Programming With jQuery Deferred: Building Blocks

$.Deferred is built on existing work and concepts from sources outside the jQuery project. To understand the feature in the fullest, it’s useful to look at those sources directly. This section will outline the origin of the pattern, which will ease you into an understanding of jQuery’s specific implementation.

1. Promises

Basically defined, a promise is a proxy for the result of an action that will happen at an unspecified time in the future.

Although they’re relatively new to jQuery, software promises have been around for a good while. The name and concept of promises dates back to a paper written in 1976 by Daniel P. Friedman and David Wise. Though language implementations are generally more academic than practical, library implementations exist for Java, Scala, Ruby, Perl, Python, and Common Lisp. Closer to home, a major JavaScript implementation has been in place in the dojo framework from version 0.9.

Because they’re so easily asynchronous, they’re particularly suited to web programming, so it was inevitable that they’d land in jQuery.

2. The Promises/A Proposal

jQuery’s specific implementation is based on the Promises/A proposal from CommonJS.

CommonJS is a group centered on interoperability in JavaScript and the growth of a healthy JavaScript ecosystem similar to the ones that have developed around other languages like Python, Ruby, and Java. The group’s main focus is on the question of modules, which the Common JS Modules API addresses directly, but they’ve worked on several other language features. One is promises. The CommonJS wiki lists several proposals for the Promises pattern. Promises/A proposal is from Kris Zyp. It’s defined as follows:

A promise represents the eventual value returned from the single completion of an operation. A promise may be in one of the three states, unfulfilled, fulfilled, and failed.

The promise may only move from unfulfilled to fulfilled, or unfulfilled to failed. Once a promise is fulfilled or failed, the promise’s value MUST not be changed The immutable characteristic of promises are important for avoiding side-effects from listeners that can create unanticipated changes in behavior and allows promises to be passed to other functions without affecting the caller, in same way that primitives can be passed to functions without any concern that the caller’s variable will be modified by the callee.

A promise is defined as an object that has a function as the value for the property ‘then’.

http://wiki.commonjs.Org/wiki/Promises/A

The following code sample presents a simplified look at the concepts presented in the Promises/A proposal.

Assuming that ajaxPromise returns a promise that can be in one of three states (unfulfilled, fulfilled, or failed), the following illustrates the general principle:

var promise = ajaxPromise() {

//XHR request

//state is set to fulfilled, unfulfilled, or failed

//depending on the result of the request return state

};

function unfulfilled(){

//handle negative result

}

function fulfilled() {

//handle successful result

}

function failed(){

//Error!

}

promise.then(

unfulfilled,

fulfilled,

failed

);

Code snippet is from pseudocode.txt

In English, ajaxPromise goes off, gets some data with an XMLHttpRequest, and when the request finishes, it returns a promise in one of the three states. The then() method routes the result to one of three functions designed to handle that state. None of that logic is bound to ajaxPromise itself. It’s all handled outside the function, which allows ajaxPromise to remain much more generic because less application logic is bound to it directly.

Now that you’ve got some history on the concept, in the next section, you look at the power of jQuery’s Deferred implementation.

Source: Otero Cesar, Rob Larsen (2012), Professional jQuery, John Wiley & Sons, Inc

Leave a Reply

Your email address will not be published. Required fields are marked *