-
Notifications
You must be signed in to change notification settings - Fork 4
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Hot/Cold promises #8
Comments
I'm not really seeing why this is useful. Is it to save two parenthesis? I.e. |
Yes and no, it makes sense only in fluent APIs. The onStart event would still only be fired once regardless of how many times you trigger it, so if you had a function A good example of this kind of API in use is superagent which is an AJAX library with a fluent API. superagent
.post('/api/pet')
.send({ name: 'Manny', species: 'cat' })
.end(function(res){
}); The superagent request object is one of those dreaded superagent
.post('/api/pet')
.send({ name: 'Manny', species: 'cat' })
.then(function(res){
})
.done(); The alternative without hot/cold promises would be: superagent
.post('/api/pet')
.send({ name: 'Manny', species: 'cat' })
.start()
.then(function(res){
})
.done(); I suspect this won't be something for the core spec tbh, but I wanted to see if anyone else had done something similar. |
I think without hot/cold promises I'd be tempted to refactor somewhat and go for something like: superagent
.path('/api/pet')
.send({ name: 'Manny', species: 'cat' })
.post()
.then(function(res){
})
.done(); where |
@ForbesLindesay I do foresee the need for lazy promises, objects that are not promises so much as they are query builders that have the promise interface, such that the first promise method called starts the work. Despite thinking about making such things for more than a year, I’m yet to actually make one, so I’m not qualified to comment on any proposed standard. I suspect it might be too early to gather a quorum to drive a spec. |
Interesting idea. My knee jerk reaction was to qualify these as something other than a promise, but I can see how they are analogous in terms of API for expressiveness, different only in the separation of the timing of calling the executor function (supposing |
I have been working a fluent API (using https://github.com/kriskowal/q) for making AJAX requests, that is similar in concept to the one described by @ForbesLindesay and from the start I always had the idea of allowing this kind of chaining without incurring unnecessary requests (inspired by this article http://blog.jcoglan.com/2013/03/30/callbacks-are-imperative-promises-are-functional-nodes-biggest-missed-opportunity/). Does anyone know of any plugin or experimental implementation of this for Q? Thanks! |
@lfac-pt there is https://npmjs.org/package/lazy-promise, which is Promises/A+ compatible. |
Nice, thank you :) |
I often find myself wanting to create promises that do nothing until you call then on them. Is it just me, or are other people doing this too? If other people are too then should we consider how we support this in resolvers.
Options:
.onStart(fn)
method to the resolver object (only viable option for Return a deferred #2)fn
when you create the promisenew Promise(fn, {cold: true})
The text was updated successfully, but these errors were encountered: