Repository navigation
Feature request: Promise support #263
Description
Activity
It should be possible to promisify the exposed interface, and it will be even easier with the upcoming v1 :)
i don't think we will do this for the v0 branch, but we might consider it on the v1 branch.
Personally I think letting the user promisify the interface is the superior option, as this is easy and limits the scope of this lib. I am open to discussion on this point, though.
Is there a timeline for V1?
I'd consider creating a patch if you'd be interested in the feature (and it's going to be released in the near future)
The timeline is "when we've checked most or all things off our list" #238 -- my best guess is quite soon after my summer holiday is up. Early to mid september, probably.
Fair enough. Starting to chew on this a little bit.
Can you explain the rationale behind using nextTick for calling callbacks in many places rather than calling them directly?
Let me know if there's a better place to post a question like this.
A function that takes a callback should never call that callback before yielding to the event loop. Using http or fs or similar usually does this, but for consistency it may slmetimes be necessary to do this explicitly.
It is commonly expected that code like this will always print "b" before "a":
something(function(error) { console.log("a"); }); console.log("b");
Calling the callback directly in the cases you refer to would result in "a" being printed before "b".
This post also covers it nicely:
https://howtonode.org/understanding-process-next-tickConsider this example taken from the post:
var client = net.connect(8124, function() { console.log('client connected'); client.write('world!\r\n'); });
In the above case, if for some reason, net.connect() invoked the callback directly without
process.nextTick, the callback would be called immediately, and hence theclientvariable will not be initialized when the it's accessed by the callback to write to the client!And for what it's worth, I'd love for promises to be supported out of the box in v1. I personally yield promises in generator functions in most of my projects and I hate having to promisify or thunkify external library functions manually. I love it when libraries provide either a callback or promise interface (if a callback is omitted).
Alright :-) let's do it
For your consideration #264
Closing this as PR was merged successfully. 😄
Functions that take a callback should return a promise if no callback is provided.