q
Last updated
Last updated
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.
With a promise library, you can flatten the pyramid.
With this approach, you also get implicit error propagation, just like try
, catch
, and finally
. An error in promisedStep1
will flow all the way to the catch
function, where it’s caught and handled. (Here promisedStepN
is a version of stepN
that returns a promise.)
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.
The Q module can be loaded as:
A <script>
tag (creating a Q
global variable): ~2.5 KB minified and gzipped.
An AMD module
A component as microjs/q
Using bower as q#^1.4.1
Q can exchange promises with jQuery, Dojo, When.js, WinJS, and more.
Our wiki contains a number of useful resources, including:
A method-by-method Q API reference.
A growing examples gallery, 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.
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.
If you want materials that introduce the promise concept generally, and the below tutorial isn't doing it for you, check out our collection of presentations, blog posts, and podcasts.
A guide for those coming from jQuery's $.Deferred
.
We'd also love to have you join the Q-Continuum mailing list.
Promises have a then
method, which you can use to get the eventual return value (fulfillment) or thrown exception (rejection).
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.
In this tutorial, we begin with how to consume and work with promises. We'll talk about how to create them, and thus create functions like promiseMeSomething
that return promises, below.
The then
method returns a promise, which in this example, I’m assigning to outputPromise
.
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
:
If the input promise gets fulfilled and you omit the fulfillment handler, the value will go to outputPromise
:
Q promises provide a fail
shorthand for then
when you are only interested in handling the 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.
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
.
There are two ways to chain promises. You can chain promises either inside or outside handlers. The next two examples are equivalent.
The only difference is nesting. It’s useful to nest handlers if you need to capture multiple input values in your closure.
You can turn an array of promises into a promise for the whole, fulfilled array using all
.
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 received promises fails first gets handled by the rejection handler.
But spread
calls all
initially, so you can skip it in chains.
The all
function returns a promise for an array of values. When this promise is fulfilled, the array contains the fulfillment values of the original promises, in the same order as those promises. If one of the given promises is rejected, the returned promise is immediately rejected, 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 allSettled
.
The any
function accepts an array of promises and returns a promise that is fulfilled by the first given promise to be fulfilled, or rejected if all of the given promises are rejected.
If you have a number of promise-producing functions that need to be run sequentially, you can of course do so manually:
However, if you want to run a dynamically constructed sequence of functions, you'll want something like this:
You can make this slightly more compact using reduce
:
Or, you could use the ultra-compact version:
One sometimes-unintuitive aspect of promises is that if you throw an exception in the fulfillment handler, it will not be caught by the error handler.
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:
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
:
Like fail
, Q also provides a shorthand for progress callbacks called progress
:
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,
Or, end it.
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.
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.
You can also use fcall
to get a promise for an exception.
As the name implies, fcall
can call functions, or even promised functions. This uses the eventualAdd
function above to add two numbers.
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.
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 is a simplified implementation of Q.delay
.
This is a simplified implementation of Q.timeout
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.
Below is an example of how to use this requestOkText
function:
Using Q.Promise
This is an alternative promise-creation API that has the same power as the deferred concept, but without introducing another conceptual entity.
Rewriting the requestOkText
example above using Q.Promise
:
If requestOkText
were to throw an exception, the returned promise would be rejected with that thrown exception as the rejection reason.
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
.
All of the other methods on a promise have static analogs with the same name.
The following are equivalent:
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.
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.
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.
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-Connection.
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
with
If you're working with functions that make use of the Node.js callback pattern, where callbacks are in the form of function(err, result)
, Q provides a few useful utility functions for converting between them. The most straightforward are probably Q.nfcall
and Q.nfapply
("Node function call/apply") for calling Node.js-style functions and getting back a promise:
If you are working with methods, instead of simple functions, you can easily run in to the usual problems where passing a method to another function—like Q.nfcall
—"un-binds" the method from its owner. To avoid this, you can either use Function.prototype.bind
or some nice shortcut methods we provide:
You can also create reusable wrappers with Q.denodeify
or Q.nbind
:
Finally, if you're working with raw deferred objects, there is a makeNodeResolver
method on deferreds that can be handy:
Q comes with optional 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:
usually would give a rather unhelpful stack trace looking something like
But, if you turn this feature on by setting
then the above code gives a nice stack trace to the tune of
Note how you can see 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.
In node.js, this feature can also be enabled through the Q_DEBUG environment variable:
This will enable long stack support in every instance of Q.
This feature does come with somewhat-serious performance and memory overhead, however. If you're working with lots of promises, or trying to scale a server to many users, you should probably keep it off. But in development, go for it!
You can view the results of the Q test suite in your browser!
Copyright 2009–2017 Kristopher Michael Kowal and contributors MIT License (enclosed)