3 ms·
Unfortunately, in practice promises end up making your code more difficult to reason about by adding cruft and unnecessary abstraction. They're also very limiti
by eldude 14y ago
Unfortunately, in practice promises end up making your code more difficult to reason about by adding cruft and unnecessary abstraction. They're also very limiting from a control-flow perspective.
This is especially noticeable when you have branching behavior / want to resolve a promise early[1]:
Branching with promises:
function doTask(task, callback) {
return Q.ncall(task.step1, task)
.then(function(result1) {
if (result1) {
return result1;
} else {
return continueTasks(task);
}
})
.nodeify(callback)
}
function continueTasks(task) {
return Q.ncall(task.step2, task);
.then(function(result2) {
return Q.ncall(task.step3, task);
})
}
As opposed to with stepdown[2]:
function doTask(task, callback) {
$$([
$$.stepCall(task.step1),
function($, result1) {
if (result1) return $.end(null, result1)
},
$$.stepCall(task.step2),
$$.stepCall(task.step3)
], callback)
}
I would really love for a post to include a non-trivial problem implemented with promises, vanilla callbacks, and async (and I'd be happy to add a stepdown equivalent), and allow people to see for themselves (how in my opinion promises make code harder to read).
[1] http://stackoverflow.com/questions/11302271/how-to-properly-abort-a-node-js-promise-chain-using-q http://stackoverflow.com/questions/11302271/how-to-properly-...
[2] https://github.com/Schoonology/stepdown https://github.com/Schoonology/stepdown (docs need updating, view tests for documentation)