I’ve just started using node, and one thing I’ve quickly noticed is how quickly callbacks can build up to a silly level of indentation:
doStuff(arg1, arg2, function(err, result) {
doMoreStuff(arg3, arg4, function(err, result) {
doEvenMoreStuff(arg5, arg6, function(err, result) {
omgHowDidIGetHere();
});
});
});
The official style guide says to put each callback in a separate function, but that seems overly restrictive on the use of closures, and making a single object declared in the top level available several layers down, as the object has to be passed through all the intermediate callbacks.
Is it ok to use function scope to help here? Put all the callback functions that need access to a global-ish object inside a function that declares that object, so it goes into a closure?
function topLevelFunction(globalishObject, callback) {
function doMoreStuffImpl(err, result) {
doMoreStuff(arg5, arg6, function(err, result) {
callback(null, globalishObject);
});
}
doStuff(arg1, arg2, doMoreStuffImpl);
}
and so on for several more layers…
Or are there frameworks etc to help reduce the levels of indentation without declaring a named function for every single callback? How do you deal with the callback pyramid?
1
Promises provide a clean separation of concerns between asynchronous
behavior and the interface so asynchronous functions can be called
without callbacks, and callback interaction can be done on the generic
promise interface.
There is multiple implementations of “promises”:
- node-promise
- promised-io
- or the most popular Q
For example you can rewrite this nested callbacks
http.get(url.parse("http://test.com/"), function(res) {
console.log(res.statusCode);
http.get(url.parse(res.headers["location"]), function(res) {
console.log(res.statusCode);
});
});
like
httpGet(url.parse("http://test.com/")).then(function (res) {
console.log(res.statusCode);
return httpGet(url.parse(res.headers["location"]));
}).then(function (res) {
console.log(res.statusCode);
});
Instead of callback in callback a(b(c())) you chain the “.then” a().then(b()).then(c()).
An introduction here: http://howtonode.org/promises
2
As an alternative to promises you should have a look at the yield keyword in combination with generator functions which will be introduced in EcmaScript 6. Both are available today in Node.js 0.11.x builds, but require that you additionally specify the --harmony flag when running Node.js:
$ node --harmony app.js
Using those constructs and a library such as TJ Holowaychuk’s co allow you to write asynchronous code in a style that looks like synchronous code, although it still runs in an asynchronous way. Basically, these things together implement co-routine support for Node.js.
Basically, what you need to do is to write a generator function for the code that runs asynchronous stuff, call the async stuff in there, but prefix it with the yield keyword. So, in the end your code looks like:
var run = function * () {
var data = yield doSomethingAsync();
console.log(data);
};
To run this generator function you need a library such as the before-mentioned co. The call then looks like:
co(run);
Or, to put it inline:
co(function * () {
// ...
});
Please note that from generator functions you can call other generator functions, all you need to do is prefix them with yield again.
For an introduction to this topic, search Google for terms such as yield generators es6 async nodejs and you should find tons of information. It takes a while to get used to it, but once you get it, you don’t want to go back ever.
Please note that this does not only provide you with a nicer syntax to call functions, it also allows you to use the usual (synchronous) control flow logic stuff, such as for loops or try / catch. No more messing around with lots of callbacks and all these things.
Good luck and have fun :-)!
You now have package asyncawait, with a very close syntax to what should be the future native support of await & async in Node.
Basically it allows you to write asynchronous code looking synchronous, reducing LOC & indenting levels dramatically, with the tradeoff of a slight performance loss (package owner’s numbers are 79% speed compared to raw callbacks), hopefully reduced when native support will be available.
Still a good choice to get out of callback hell / pyramid of doom nightmare IMO, when performance is not the primary concern & where synchronous writing style better suits your project’s needs.
Basic example from package doc:
var foo = async (function() {
var resultA = await (firstAsyncCall());
var resultB = await (secondAsyncCallUsing(resultA));
var resultC = await (thirdAsyncCallUsing(resultB));
return doSomethingWith(resultC);
});