On Fri, Nov 9, 2012 at 4:33 AM, David Bruant <[email protected]> wrote:
> Hi,
>
> In this message, I'll be sharing some experience I've had with the Q
> library. I have worked with it for about 7-8 months in a medium/big Node.js
> application (closed source, so I can't link, sorry).
> I'll be covering only the parts that I have used during this experience.
> It's related to my own writing style and I don't mean that the rest is
> useless and should be thrown away, but the subset I'll be covering here has
> proven to be sufficient to my needs for several months.
>
> I would be interested if others could share their experience if they had a
> different way of using promises.
>
I also used Q (a slightly older version) for several months before removing
it because of cost/benefit.
>
> # the Q API
> ## A Q Deferred is a {promise, reject, resolve} object. Only the deferred
> holder can resolve the promise (and not the promise holder), addressing the
> security issue that's been raised on the list.
> You create a Deferred instance by calling Q.defer()
>
> Typically, when trying to promise-ify async APIs, you end up doing
> something like (and that's probably also how things are done internally):
>
> function query(myQuery){
> var def = Q.defer();
>
> db.query(myQuery, function(err, data){
> if(err)
> def.reject(err)
> else
> def.resolve(data)
> })
>
> return def.promise;
> }
>
I had lots of code like that.
>
> ## A Q Promise is a {then, fail} object.
> Given the previous code, it's possible to do:
>
> var someData1P = query(q1);
> someData1P.then(function(data)**{
> // do something with data
> });
> someData1P.fail(function(**error){
> // handle the error
> });
>
> Both then and fail return another promise for the result of the callback
>
Note these callbacks: promise based code is very callback-y.
....
>
>
> ## Q.all
> My favorite feature is the Q.all function. Q.all accepts an array of
> promises and returns a promise which will be fulfilled when all promises
> are.
...
> I used this extensively and it's been extremely helpful. Personally, to
> synchronize different async operations, I've never read code more elegant
> than what Q.all offers. I'm interested in hearing what other's experience
> is on that point.
>
I agree that this is the most valuable feature and the one that got me to
try Q and stick with it for a while. However, in my experience this
feature is only needed a few times in an application.
>
> # Debugging
> It's been said in other messages, one part where Q promises fell short was
> debugging.
...
>
I suppose if we stick to console logging I could agree with this very rosy
description. But Q makes breakpoint debugging essentially useless: the call
stack is gone and you have to break much more often then try to correlate
the values across breakpoints.
> I think I've shared pretty much all my experience and thoughts on the
> topic. I feel that overall, the Q API is really good to work with promises
> and my opinion is that a standard promise feature should have the same
> features (I however don't care about the exact names of methods).
I agree that Q is exceptionally well done, so much so that I came away much
less enthusiastic about the promise concept overall.
jjb
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
