Write Better JavaScript with Promises(davidwalsh.name) |
Write Better JavaScript with Promises(davidwalsh.name) |
I currently use use callbacks and caolan/async on node.js, using in-place callbacks where simple and async methods where things get complex. It's been working very well so far, and it avoids my biggest issue with promises, which is that it seems I'd need all the modules I want to use to support promises, which they surely don't, and mixing two styles seems worse than picking a poison.
Maybe someone can show me why my reasoning is flawed, though.
var b = require('bluebird'), request = b.promisify(require('request'));
request(...).then(...)
When I used promises for real in a section of my code processing data:
1) I found it hard to use mostly because of all the work I had to do to "lift" non promise code up into promises, before I could use them.
2) When chaining them, it wasn't clear how you would handle a "fan-out", where a piece of data generated an array, which you then had to process with callbacks.
3) Unless I inserted a fail() after every then(), it was hard to tell where exactly in the chain something failed, and the stack trace wasn't very helpful.
I suspect maybe I'm doing something wrong--that even though you can chain promises sequentially, you generally want to make functions using promises, that you can then chain? I still haven't seen well written promise code. Anyone got examples other than toy examples?
And you can always use something like bluebird's promisify if you're combining promises with existing callback code.
1) There is not much work in promisifying libraries, for example the entire redis library can be promisified using 2 lines:
var Promise = require("bluebird");
var redis = require("redis");
Promise.promisifyAll(redis.RedisClient.prototype);
Promise.promisifyAll(redis.Multi.prototype);
2) Mixing callbacks and promises will result in very ugly code, see 1) to avoid it.
3) Forget about .fail(), this is not how promise error handling works. Use `.catch()` like you would use try catch. In your case that means not using it at all - then a full stack trace is automatically logged. Try catch is meant to be used with expected errors like file not existing, not bugs.
https://github.com/petkaantonov/bluebird/blob/master/API.md#...