Andrew,
For the love of all that is dear to us, Use promises, do not support
callbacks, don't even think about supporting both.
There is a reason why promises are becoming part of the standard in ECMA 6.
Here are a few of many reasons why to choose promises:
- It prevent deep indentation
- It always you to pass on asynchronous operations
- Asyncronous callstacks and consistent error handling ( you want this )
- How many types have you typed *if (err) throw err *or *if (err)
console.warn(err) ?*
- Refactoring in callback styled code is extremely tedious to the point
where it would be almost reasonable to say it's impossible
- Improved readability trough more logical control flow
- Integration with coroutines ( you want this )
On Tuesday, April 15, 2014 6:20:05 AM UTC+2, Andrew de Andrade wrote:
>
> So at work we're working on a bunch of node modules that will eventually
> be published as open-source and I'm in favor of callbacks and two of my
> co-workers are in favor of promises. We've discussed supporting both API
> interfaces and I was curious what the general consensus of the community
> was with respect to supporting both and the best way to name functions and
> methods to support both.
>
> That being said, there are three obvious choices:
>
> (a) two function types: (1) synchronous functions; and (2) async functions
> that return promises but also handle callbacks
>
> var value = myFunctionSync();
> myFunction(callback);
> var promise = myFunction();
>
> this approach has a tiny performance overhead (since you have to check if
> the last argument is a function to determine if you should return a promise
> or execute that function as the callback) and makes all the functions a
> little convoluted (unless you make one higher order function that you apply
> to all your callback functions to support both APIs). Furthermore async,
> higher order, overloaded functions or variable arity functions become
> impossible since you can't necessarily assume that the last argument is
> always the callback.
>
> (b) three function types: (1) synchronous functions; (2) async callback
> functions; and (3) async promise functions
>
> var value = myFunctionSync();
> myFunction(callback);
> var promise = myFunctionDeferred();
>
> this is ugly but explicit in terms of what to expect and permits the most
> flexibility.
>
> (c) two function types: (1) synchronous functions; (2) async callback
> functions;
>
> var value = myFunctionSync();
> myFunction(callback);
>
> and promise support is left up to the user by using a nodeify() method
> from a promise library. This is my preference, but won't make my co-workers
> happy.
>
>
> With all this in mind, what's the general consensus of the NodeJS
> community on this issue? I searched google and the archives and could not
> find any blog posts or discussions that address this particular issue. What
> are the pros and cons of each approach? What if any libraries implement
> options (a) or (b)? etc.
>
>
>
--
--
Job Board: http://jobs.nodejs.org/
Posting guidelines:
https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
You received this message because you are subscribed to the Google
Groups "nodejs" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/nodejs?hl=en?hl=en
---
You received this message because you are subscribed to the Google Groups
"nodejs" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/d/optout.
