Promises

John J Barton johnjbarton at johnjbarton.com
Fri Nov 9 09:01:07 PST 2012


On Fri, Nov 9, 2012 at 4:33 AM, David Bruant <bruant.d at gmail.com> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20121109/61b74ed8/attachment-0001.html>


More information about the es-discuss mailing list