q

What is q?

The 'q' npm package is a library for creating and managing promises in JavaScript. It provides a robust set of tools for working with asynchronous operations, allowing developers to write cleaner, more maintainable code by avoiding the 'callback hell' that can occur with deeply nested callbacks.

What are q's main functionalities?

Creating Promises

This feature allows the creation of a new promise using Q.defer(). The deferred object has a promise property and methods for resolving or rejecting the promise.

const Q = require('q');
const deferred = Q.defer();

function asyncOperation() {
  // Perform some asynchronous operation
  setTimeout(() => {
    // Resolve the promise after 1 second
    deferred.resolve('Operation completed');
  }, 1000);
  return deferred.promise;
}

asyncOperation().then(result => console.log(result));

Promise Chaining

This feature demonstrates how promises can be chained together, with the output of one promise being passed as input to the next.

const Q = require('q');

function firstAsyncOperation() {
  var deferred = Q.defer();
  setTimeout(() => deferred.resolve(1), 1000);
  return deferred.promise;
}

function secondAsyncOperation(result) {
  var deferred = Q.defer();
  setTimeout(() => deferred.resolve(result + 1), 1000);
  return deferred.promise;
}

firstAsyncOperation()
  .then(secondAsyncOperation)
  .then(result => console.log('Final result:', result));

Error Handling

This feature shows how to handle errors in promise-based workflows. The catch method is used to handle any errors that occur during the promise's execution.

const Q = require('q');

function mightFailOperation() {
  var deferred = Q.defer();
  setTimeout(() => {
    if (Math.random() > 0.5) {
      deferred.resolve('Success!');
    } else {
      deferred.reject(new Error('Failed!'));
    }
  }, 1000);
  return deferred.promise;
}

mightFailOperation()
  .then(result => console.log(result))
  .catch(error => console.error(error.message));

Other packages similar to q

bluebird

Bluebird is a fully-featured promise library with a focus on innovative features and performance. It is known for being one of the fastest promise libraries and includes utilities for concurrency, such as Promise.map and Promise.reduce, which are not present in 'q'.

when

When is another lightweight Promise library that offers similar functionality to 'q'. It provides a solid API for creating and managing promises but is generally considered to have a smaller footprint and to be more modular than 'q'.

promise

This package is a simple implementation of Promises/A+. It is smaller and may be more straightforward than 'q' for those who only need basic promise functionality without the additional utilities provided by 'q'.

README

If a function cannot return a value or throw an exception without blocking, it can return a promise instead. A promise is an object that represents the return value or the thrown exception that the function may eventually provide. A promise can also be used as a proxy for a remote object to overcome latency.

On the first pass, promises can mitigate the “Pyramid of Doom”: the situation where code marches to the right faster than it marches forward.

step1(function (value1) {
    step2(value1, function(value2) {
        step3(value2, function(value3) {
            step4(value3, function(value4) {
                // Do something with value4
            });
        });
    });
});

With a promise library, you can flatten the pyramid.

Q.fcall(step1)
.then(step2)
.then(step3)
.then(step4)
.then(function (value4) {
    // Do something with value4
}, function (error) {
    // Handle any error from step1 through step4
})
.done();

With this approach, you also get implicit error propagation, just like try, catch, and finally. An error in step1 will flow all the way to step5, where it’s caught and handled.

The callback approach is called an “inversion of control”. A function that accepts a callback instead of a return value is saying, “Don’t call me, I’ll call you.”. Promises un-invert the inversion, cleanly separating the input arguments from control flow arguments. This simplifies the use and creation of API’s, particularly variadic, rest and spread arguments.

Getting Started

The Q module can be loaded as:

• A <script> tag (creating a Q global variable): ~3 KB minified and gzipped.
• A Node.js and CommonJS module, available in npm as the q package
• An AMD module
• A component as microjs/q
• Using bower as microjs/q
• Using NuGet as Q

Q can exchange promises with jQuery, Dojo, When.js, WinJS, and more. Additionally, there are many libraries that produce and consume Q promises for everything from file system/database access or RPC to templating. For a list of some of the more popular ones, see Libraries.

Please join the Q-Continuum mailing list.

Tutorial

Promises have a then method, which you can use to get the eventual return value (fulfillment) or thrown exception (rejection).

promiseMeSomething()
.then(function (value) {
}, function (reason) {
});

If promiseMeSomething returns a promise that gets fulfilled later with a return value, the first function (the fulfillment handler) will be called with the value. However, if the promiseMeSomething function gets rejected later by a thrown exception, the second function (the rejection handler) will be called with the exception.

Note that resolution of a promise is always asynchronous: that is, the fulfillment or rejection handler will always be called in the next turn of the event loop (i.e. process.nextTick in Node). This gives you a nice guarantee when mentally tracing the flow of your code, namely that then will always return before either handler is executed.

Propagation

The then method returns a promise, which in this example, I’m assigning to outputPromise.

var outputPromise = getInputPromise()
.then(function (input) {
}, function (reason) {
});

The outputPromise variable becomes a new promise for the return value of either handler. Since a function can only either return a value or throw an exception, only one handler will ever be called and it will be responsible for resolving outputPromise.

• If you return a value in a handler, outputPromise will get fulfilled.

• If you throw an exception in a handler, outputPromise will get rejected.

• If you return a promise in a handler, outputPromise will “become” that promise. Being able to become a new promise is useful for managing delays, combining results, or recovering from errors.

If the getInputPromise() promise gets rejected and you omit the rejection handler, the error will go to outputPromise:

var outputPromise = getInputPromise()
.then(function (value) {
});

If the input promise gets fulfilled and you omit the fulfillment handler, the value will go to outputPromise:

var outputPromise = getInputPromise()
.then(null, function (error) {
});

Q promises provide a fail shorthand for then when you are only interested in handling the error:

var outputPromise = getInputPromise()
.fail(function (error) {
});

If you are writing JavaScript for modern engines only or using CoffeeScript, you may use catch instead of fail.

Promises also have a fin function that is like a finally clause. The final handler gets called, with no arguments, when the promise returned by getInputPromise() either returns a value or throws an error. The value returned or error thrown by getInputPromise() passes directly to outputPromise unless the final handler fails, and may be delayed if the final handler returns a promise.

var outputPromise = getInputPromise()
.fin(function () {
    // close files, database connections, stop servers, conclude tests
});

• If the handler returns a value, the value is ignored
• If the handler throws an error, the error passes to outputPromise
• If the handler returns a promise, outputPromise gets postponed. The eventual value or error has the same effect as an immediate return value or thrown error: a value would be ignored, an error would be forwarded.

If you are writing JavaScript for modern engines only or using CoffeeScript, you may use finally instead of fin.

Chaining

There are two ways to chain promises. You can chain promises either inside or outside handlers. The next two examples are equivalent.

return getUsername()
.then(function (username) {
    return getUser(username)
    .then(function (user) {
        // if we get here without an error,
        // the value returned here
        // or the exception thrown here
        // resolves the promise returned
        // by the first line
    })
});

return getUsername()
.then(function (username) {
    return getUser(username);
})
.then(function (user) {
    // if we get here without an error,
    // the value returned here
    // or the exception thrown here
    // resolves the promise returned
    // by the first line
});

The only difference is nesting. It’s useful to nest handlers if you need to capture multiple input values in your closure.

function authenticate() {
    return getUsername()
    .then(function (username) {
        return getUser(username);
    })
    // chained because we will not need the user name in the next event
    .then(function (user) {
        return getPassword()
        // nested because we need both user and password next
        .then(function (password) {
            if (user.passwordHash !== hash(password)) {
                throw new Error("Can't authenticate");
            }
        });
    });
}

Combination

You can turn an array of promises into a promise for the whole, fulfilled array using all.

return Q.all([
    eventualAdd(2, 2),
    eventualAdd(10, 20)
]);

If you have a promise for an array, you can use spread as a replacement for then. The spread function “spreads” the values over the arguments of the fulfillment handler. The rejection handler will get called at the first sign of failure. That is, whichever of the recived promises fails first gets handled by the rejection handler.

function eventualAdd(a, b) {
    return Q.spread([a, b], function (a, b) {
        return a + b;
    })
}

But spread calls all initially, so you can skip it in chains.

return getUsername()
.then(function (username) {
    return [username, getUser(username)];
})
.spread(function (username, user) {
});

The all function returns a promise for an array of values. If one of the given promise fails, the whole returned promise fails, not waiting for the rest of the batch. If you want to wait for all of the promises to either be fulfilled or rejected, you can use allResolved.

Q.allResolved(promises)
.then(function (promises) {
    promises.forEach(function (promise) {
        if (promise.isFulfilled()) {
            var value = promise.valueOf();
        } else {
            var exception = promise.valueOf().exception;
        }
    })
});

Sequences

If you have a number of promise-producing functions that need to be run sequentially, you can of course do so manually:

return foo(initialVal).then(bar).then(baz).then(qux);

However, if you want to run a dynamically constructed sequence of functions, you'll want something like this:

var funcs = [foo, bar, baz, qux];

var result = Q.resolve(initialVal);
funcs.forEach(function (f) {
    result = result.then(f);
});
return result;

You can make this slightly more compact using reduce:

return funcs.reduce(function (soFar, f) {
    return soFar.then(f);
}, Q.resolve(initialVal));

Handling Errors

One sometimes-unintuive aspect of promises is that if you throw an exception in the fulfillment handler, it will not be be caught by the error handler.

return foo()
.then(function (value) {
    throw new Error("Can't bar.");
}, function (error) {
    // We only get here if "foo" fails
});

To see why this is, consider the parallel between promises and try/catch. We are try-ing to execute foo(): the error handler represents a catch for foo(), while the fulfillment handler represents code that happens after the try/catch block. That code then needs its own try/catch block.

In terms of promises, this means chaining your rejection handler:

return foo()
.then(function (value) {
    throw new Error("Can't bar.");
})
.fail(function (error) {
    // We get here with either foo's error or bar's error
});

Progress Notification

It's possible for promises to report their progress, e.g. for tasks that take a long time like a file upload. Not all promises will implement progress notifications, but for those that do, you can consume the progress values using a third parameter to then:

return uploadFile()
.then(function () {
    // Success uploading the file
}, function (err) {
    // There was an error, and we get the reason for error
}, function (progress) {
    // We get notified of the upload's progress as it is executed
});

Like fail, Q also provides a shorthand for progress callbacks called progress:

return uploadFile().progress(function (progress) {
    // We get notified of the upload's progress
});

The End

When you get to the end of a chain of promises, you should either return the last promise or end the chain. Since handlers catch errors, it’s an unfortunate pattern that the exceptions can go unobserved.

So, either return it,

return foo()
.then(function () {
    return "bar";
});

Or, end it.

foo()
.then(function () {
    return "bar";
})
.done();

Ending a promise chain makes sure that, if an error doesn’t get handled before the end, it will get rethrown and reported.

This is a stopgap. We are exploring ways to make unhandled errors visible without any explicit handling.

The Beginning

Everything above assumes you get a promise from somewhere else. This is the common case. Every once in a while, you will need to create a promise from scratch.

Using Q.fcall

You can create a promise from a value using Q.fcall. This returns a promise for 10.

return Q.fcall(function () {
    return 10;
});

You can also use fcall to get a promise for an exception.

return Q.fcall(function () {
    throw new Error("Can't do it");
});

As the name implies, fcall can call functions, or even promised functions. This uses the eventualAdd function above to add two numbers.

return Q.fcall(eventualAdd, 2, 2);

Using Deferreds

If you have to interface with asynchronous functions that are callback-based instead of promise-based, Q provides a few shortcuts (like Q.nfcall and friends). But much of the time, the solution will be to use deferreds.

var deferred = Q.defer();
FS.readFile("foo.txt", "utf-8", function (error, text) {
    if (error) {
        deferred.reject(new Error(error));
    } else {
        deferred.resolve(text);
    }
});
return deferred.promise;

Note that a deferred can be resolved with a value or a promise. The reject function is a shorthand for resolving with a rejected promise.

// this:
deferred.reject(new Error("Can't do it"));

// is shorthand for:
var rejection = Q.fcall(function () {
    throw new Error("Can't do it");
});
deferred.resolve(rejection);

This is a simplified implementation of Q.delay.

function delay(ms) {
    var deferred = Q.defer();
    setTimeout(deferred.resolve, ms);
    return deferred.promise;
}

This is a simplified implementation of Q.timeout

function timeout(promise, ms) {
    var deferred = Q.defer();
    Q.when(promise, deferred.resolve);
    Q.when(delay(ms), function () {
        deferred.reject(new Error("Timed out"));
    });
    return deferred.promise;
}

Finally, you can send a progress notification to the promise with deferred.notify.

For illustration, this is a wrapper for XML HTTP requests in the browser. Note that a more thorough implementation would be in order in practice.

function requestOkText(url) {
    var request = new XMLHttpRequest();
    var deferred = Q.defer();

    request.open("GET", url, true);
    request.onload = onload;
    request.onerror = onerror;
    request.onprogress = onprogress;
    request.send();

    function onload() {
        if (request.status === 200) {
            deferred.resolve(request.responseText);
        } else {
            onerror();
        }
    }

    function onerror() {
        deferred.reject("Can't XHR " + JSON.stringify(url));
    }

    function onprogress(event) {
        deferred.notify(event.loaded / event.total);
    }

    return deferred.promise;
}

The Middle

If you are using a function that may return a promise, but just might return a value if it doesn’t need to defer, you can use the “static” methods of the Q library.

The when function is the static equivalent for then.

return Q.when(valueOrPromise, function (value) {
}, function (error) {
});

All of the other methods on a promise have static analogs with the same name.

The following are equivalent:

return Q.all([a, b]);

return Q.fcall(function () {
    return [a, b];
})
.all();

When working with promises provided by other libraries, you should convert it to a Q promise. Not all promise libraries make the same guarantees as Q and certainly don’t provide all of the same methods. Most libraries only provide a partially functional then method. This thankfully is all we need to turn them into vibrant Q promises.

return Q.when($.ajax(...))
.then(function () {
});

If there is any chance that the promise you receive is not a Q promise as provided by your library, you should wrap it using a Q function. You can even use Q.invoke as a shorthand.

return Q.invoke($, 'ajax', ...)
.then(function () {
});

Over the Wire

A promise can serve as a proxy for another object, even a remote object. There are methods that allow you to optimistically manipulate properties or call functions. All of these interactions return promises, so they can be chained.

direct manipulation         using a promise as a proxy
--------------------------  -------------------------------
value.foo                   promise.get("foo")
value.foo = value           promise.put("foo", value)
delete value.foo            promise.del("foo")
value.foo(...args)          promise.post("foo", [args])
value.foo(...args)          promise.invoke("foo", ...args)
value(...args)              promise.fapply([args])
value(...args)              promise.fcall(...args)

If the promise is a proxy for a remote object, you can shave round-trips by using these functions instead of then. To take advantage of promises for remote objects, check out Q-Comm.

Even in the case of non-remote objects, these methods can be used as shorthand for particularly-simple fulfillment handlers. For example, you can replace

return Q.fcall(function () {
    return [{ foo: "bar" }, { foo: "baz" }];
})
.then(function (value) {
    return value[0].foo;
});

with

return Q.fcall(function () {
    return [{ foo: "bar" }, { foo: "baz" }];
})
.get(0)
.get("foo");

Adapting Node

There is a makeNodeResolver method on deferreds that is handy for the NodeJS callback pattern.

var deferred = Q.defer();
FS.readFile("foo.txt", "utf-8", deferred.makeNodeResolver());
return deferred.promise;

And there are Q.nfcall and Q.ninvoke for even shorter expression.

return Q.nfcall(FS.readFile, "foo.txt", "utf-8");

return Q.ninvoke(FS, "readFile", "foo.txt", "utf-8");

There is also a Q.nfbind function that that creates a reusable wrapper.

var readFile = Q.nfbind(FS.readFile);
return readFile("foo.txt", "utf-8");

Note that, since promises are always resolved in the next turn of the event loop, working with streams can be tricky. The essential problem is that, since Node does not buffer input, it is necessary to attach your "data" event listeners immediately, before this next turn comes around. There are a variety of solutions to this problem, and even some hope that in future versions of Node it will be ameliorated.

Long Stack Traces

Q comes with experimental support for “long stack traces,” wherein the stack property of Error rejection reasons is rewritten to be traced along asynchronous jumps instead of stopping at the most recent one. As an example:

function theDepthsOfMyProgram() {
  Q.delay(100).done(function explode() {
    throw new Error("boo!");
  });
}

theDepthsOfMyProgram();

gives a strack trace of:

Error: boo!
    at explode (/path/to/test.js:3:11)
From previous event:
    at theDepthsOfMyProgram (/path/to/test.js:2:16)
    at Object.<anonymous> (/path/to/test.js:7:1)

Note how you can see the the function that triggered the async operation in the stack trace! This is very helpful for debugging, as otherwise you end up getting only the first line, plus a bunch of Q internals, with no sign of where the operation started.

This feature comes with some caveats, however. First, it does not (yet!) stitch together multiple asynchronous steps. You only get the one immediately prior to the operation that throws. Secondly, it comes with a performance penalty, and so if you are using Q to create many promises in a performance-critical situation, you will probably want to turn it off.

To turn it off, set

Q.longStackJumpLimit = 0;

Then you stack traces will revert to their usual unhelpful selves:

Error: boo!
    at explode (/path/to/test.js:3:11)
    at _fulfilled (/path/to/test.js:q:54)
    at resolvedValue.promiseDispatch.done (/path/to/q.js:823:30)
    at makePromise.promise.promiseDispatch (/path/to/q.js:496:13)
    at pending (/path/to/q.js:397:39)
    at process.startup.processNextTick.process._tickCallback (node.js:244:9)

Reference

A method-by-method Q API reference is available on the wiki.

More Examples

A growing examples gallery is available on the wiki, showing how Q can be used to make everything better. From XHR to database access to accessing the Flickr API, Q is there for you.

---

Copyright 2009-2012 Kristopher Michael Kowal MIT License (enclosed)

Changelog

0.9.0

This release removes many layers of deprecated methods and brings Q closer to alignment with Mark Miller’s TC39 [strawman][] for concurrency. At the same time, it fixes many bugs and adds a few features around error handling. Finally, it comes with an updated and comprehensive [API Reference][].

API Cleanup

The following deprecated or undocumented methods have been removed. Their replacements are listed here:

<table> <thead> <tr> <th>0.8.x method</th> <th>0.9 replacement</th> </tr> </thead> <tbody> <tr> <td><code>Q.ref</code></td> <td><code>Q</code></td> </tr> <tr> <td><code>call</code>, <code>apply</code>, <code>bind</code> (*)</td> <td><code>fcall</code>/<code>invoke</code>, <code>fapply</code>/<code>post</code>, <code>fbind</code></td> </tr> <tr> <td><code>ncall</code>, <code>napply</code> (*)</td> <td><code>nfcall</code>/<code>ninvoke</code>, <code>nfapply</code>/<code>npost</code></td> </tr> <tr> <td><code>end</code></td> <td><code>done</code></td> </tr> <tr> <td><code>put</code></td> <td><code>set</code></td> </tr> <tr> <td><code>node</code></td> <td><code>nbind</code></td> </tr> <tr> <td><code>nend</code></td> <td><code>nodeify</code></td> </tr> <tr> <td><code>isResolved</code></td> <td><code>isPending</code></td> </tr> <tr> <td><code>deferred.node</code></td> <td><code>deferred.makeNodeResolver</code></td> </tr> <tr> <td><code>Method</code>, <code>sender</code></td> <td><code>dispatcher</code></td> </tr> <tr> <td><code>send</code></td> <td><code>dispatch</code></td> </tr> <tr> <td><code>view</code>, <code>viewInfo</code></td> <td>(none)</td> </tr> </tbody> </table>

(*) Use of thisp is discouraged. For calling methods, use post or invoke.

Alignment with the Concurrency Strawman

• Q now exports a Q(value) function, an alias for resolve. Q.call, Q.apply, and Q.bind were removed to make room for the same methods on the function prototype.
• invoke has been aliased to send in all its forms.
• post with no method name acts like fapply.

Error Handling

• Long stack traces can be turned off by setting Q.stackJumpLimit to zero. In the future, this property will be used to fine tune how many stack jumps are retained in long stack traces; for now, anything nonzero is treated as one (since Q only tracks one stack jump at the moment, see #144). #168
• In Node.js, if there are unhandled rejections when the process exits, they are output to the console. #115

Other

• delete and set (née put) no longer have a fulfillment value.
• Q promises are no longer frozen, which helps with performance.
• thenReject is now included, as a counterpart to thenResolve.
• The included browser nextTick shim is now faster. #195 @rkatic.

Bug Fixes

• Q now works in Internet Explorer 10. #186 @ForbesLindesay
• fbind no longer hard-binds the returned function's this to undefined. #202
• Q.reject no longer leaks memory. #148
• npost with no arguments now works. #207
• allResolved now works with non-Q promises ("thenables"). #179
• keys behavior is now correct even in browsers without native Object.keys. #192 @rkatic
• isRejected and the exception property now work correctly if the rejection reason is falsy. #198

Internals and Advanced

• The internal interface for a promise now uses dispatchPromise(resolve, op, operands) instead of sendPromise(op, resolve, ...operands), which reduces the cases where Q needs to do argument slicing.
• The internal protocol uses different operands. "put" is now "set". "del" is now "delete". "view" and "viewInfo" have been removed.
• Q.fulfill has been added. It is distinct from Q.resolve in that it does not pass promises through, nor coerces promises from other systems. The promise becomes the fulfillment value. This is only recommended for use when trying to fulfill a promise with an object that has a then function that is at the same time not a promise.