On Fri, Nov 9, 2012 at 9:01 AM, John J Barton <johnjbar...@johnjbarton.com>wrote:
> > > > On Fri, Nov 9, 2012 at 4:33 AM, David Bruant <bruan...@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. > I would like to understand this better. When you using only the .then/.when callback style, or were you using the .send/.post style to send eventual messages to the promised object? In my own code, I use mostly the .send/.post style, and I find it substantially improves readability. See <https://docs.google.com/file/d/0Bw0VXJKBgYPMU1gzQ3hkY0Vrbmc/edit> (with improved slides at < http://code.google.com/p/es-lab/downloads/detail?name=friam.pdf#makechanges>) for a particularly elegant example using promises. I would be curious how well you could express this without promises. > > >> >> # 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 > es-discuss@mozilla.org > https://mail.mozilla.org/listinfo/es-discuss > > -- Cheers, --MarkM
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
