RQ – A small JavaScript library for managing asychronicity
rq.crockford.com
RQ – A small JavaScript library for managing asychronicity
1–10 of 37 posts
Re: RQ – A small JavaScript library for managing asychronicity
#2I think I must be missing something, because this looks to me like a less-elegant reinvention of the functionality of a handful of already extant promise libraries. A library like 'when' already does all of this, and is much more composable. As an obvious example, there is no reason to clutter up your interfaces with specialized things like timeout parameters when a timeout something you can transparently wrap on any promise without changing its interface one bit.
Re: RQ – A small JavaScript library for managing asychronicity
#3I'm not sure I'll start using RQ all the time over Promises, but this does offer two nice features that Promises don't: optionals and timeouts. Optionals could easily be implemented as some like Promise.some(), while Promise.[all|some|race]() could all start taking an optional timeout parameter.
Re: RQ – A small JavaScript library for managing asychronicity
#4I'm not sure I'll start using RQ all the time over Promises, but this does offer two nice features that Promises don't: optionals and timeouts. Optionals could easily be implemented as some like Promise.some(), while Promise.[all|some|race]() could all start taking an optional timeout parameter.
A 'timeoutable' promise could be represented as (pseudocode):
Promise.any([newTimeout(1000), otherPromise])
where:
newTimeout :: Milliseconds -> Promise
If the combination of these two isn't already in Promise implementations, it should be.
Bluebird already has the timeout function with similar semantics.
https://github.com/petkaantonov/bluebird/blob/master/API.md#...
Re: RQ – A small JavaScript library for managing asychronicity
#5I'm not sure I'll start using RQ all the time over Promises, but this does offer two nice features that Promises don't: optionals and timeouts. Optionals could easily be implemented as some like Promise.some(), while Promise.[all|some|race]() could all start taking an optional timeout parameter.
The most popular[1] promises library (Bluebird) already has support for all of that, I think? .timeout() can be added to any promise chain to add a timeout, and there's .some(), .race(), .settle(), and .any(), etc. to handle various flavours of optionality.
[1]: Well, based on comments on HN and Reddit. Not sure about hard numbers, but it certainly gets talked about a lot.
Re: RQ – A small JavaScript library for managing asychronicity
#6errr. require('async')?
Re: RQ – A small JavaScript library for managing asychronicity
#7I'm not sure I'll start using RQ all the time over Promises, but this does offer two nice features that Promises don't: optionals and timeouts. Optionals could easily be implemented as some like Promise.some(), while Promise.[all|some|race]() could all start taking an optional timeout parameter.
The most popular[1] promises library (Bluebird) already has support for all of that, I think? .timeout() can be added to any promise chain to add a timeout, and there's .some(), .race(), .settle(), and .any(), etc. to handle various flavours of optionality. [1]: Well, based on comments on HN and Reddit. Not sure about hard numbers, but it certainly gets talked about a lot.
I'm more interested in these sorts of features being in the ES6 Promises implementation. I expect that given a lot of new Web APIs are going to be using the native promises, these features being in the ECMAScript promises implementation is pretty important.
Re: RQ – A small JavaScript library for managing asychronicity
#8I think I must be missing something, because this looks to me like a less-elegant reinvention of the functionality of a handful of already extant promise libraries. A library like 'when' already does all of this, and is much more composable. As an obvious example, there is no reason to clutter up your interfaces with specialized things like timeout parameters when a timeout something you can transparently wrap on any…
Yeah I feel the same way. So many others do this; hell I'm even building a few of these into my current library. Seems like better language constructs for handling asynchronous stuff will be nice (like ES6 promises though obviously it doesn't do everything this library does but it does enough to make it easier to do when needed).
Edit: Also where are the unit tests?
Re: RQ – A small JavaScript library for managing asychronicity
#9I'm not sure I'll start using RQ all the time over Promises, but this does offer two nice features that Promises don't: optionals and timeouts. Optionals could easily be implemented as some like Promise.some(), while Promise.[all|some|race]() could all start taking an optional timeout parameter.
Have you looked at core.async in Clojure/ClojureScript?
Re: RQ – A small JavaScript library for managing asychronicity
#10Earlier quoted context omitted.
The most popular[1] promises library (Bluebird) already has support for all of that, I think? .timeout() can be added to any promise chain to add a timeout, and there's .some(), .race(), .settle(), and .any(), etc. to handle various flavours of optionality. [1]: Well, based on comments on HN and Reddit. Not sure about hard numbers, but it certainly gets talked about a lot.
I'm more interested in these sorts of features being in the ES6 Promises implementation. I expect that given a lot of new Web APIs are going to be using the native promises, these features being in the ECMAScript promises implementation is pretty important.
It doesn't matter at all what kind of promise flavor an API returns because promise implementations treat other implementations as interchangeable.
Even the ES6 Promises implementation supports this:
Promise.all([{
then: function(r) {
r(3);
}
}]).then(function(result) {
console.log(result);
});