Re: [nodejs] Re: Module API design for both promises and callbacks

[Alex Kocharin]

 

16.04.2014, 12:27, "willem dhaeseleer" <dhwil...@gmail.com>:

 

Hey greelgorke,

 

Great to get some feedback on my answer, I'll try to clarify my arguments some more here:

 

- It always you to pass on asynchronous operations

huh? 

  

 // foo returns promise

 var futureBar = foo();

 

 // you can know pass around futureBar to some other api or use it for later reference

 // with callbacks you will have to write your own wrapper code to get this type of "asynchronous encapsulation"

 

In this case API consumer would wrap callbacks provided by an API with promises. API doesn't have to provide promises itself.

 

And since I never saw this use-case in practice it's not really very important.

 

 

 

    - How many types have you typed if (err) throw err or if (err) console.warn(err) ?

you actually type this yourself? 

 

Off course not, but i have seen it in to much code already. 

Obviously i forgot if (err) return callback(err);

If haven't written in this style anymore for a long time.

 

- Improved readability trough more logical control flow

duh. readability is subjective.

 

Off course it's subjective, but chronological reading order is something I tend to value in most code.

Just my opinion.

 

- Integration with coroutines ( you want this )

huh? how is that connected? 

 

An example should clarify this, this uses bluebird:

This is obviously a bad use of a database, but the idea is to demonstrate how promises integrate with coroutines.

 

var getTotalFriendBalance = Promise.coroutine(function* (name) {

    var user, userFriends, x, totalBalance;

    user = yield db.getUserByName(name);

    userFriends = yield db.getFriends(user.id);

    for (x = 0; x < userFriends.length; x++) {

        totalBalance += (yield db.getAccountInfo(userFriends[x].id)).balance;

    }

    return totalBalance;

});

 

I challenge you to write this peace of code with only callbacks, I think you will find this syntax is much more intuitive and more pleasant to write.

 

Easy:

 

var getTotalFriendBalance = require('co')(function* (name) {

    var user, userFriends, x, totalBalance;

    user = yield db.getUserByName.bind(db, name);

    userFriends = yield db.getFriends.bind(db, user.id);

    for (x = 0; x < userFriends.length; x++) {

        totalBalance += (yield db.getAccountInfo.bind(db, userFriends[x].id)).balance;

    }

    return totalBalance;

})();

 

 

 

This is only possible because all asynchronous methods here return promises (or thenables) that can be used by the coroutine.

 

I hope this clarifies my personal opinion on why promises are better. 

 

 

On Wednesday, April 16, 2014 9:50:22 AM UTC+2, greelgorke wrote:

inline

Am Mittwoch, 16. April 2014 08:46:48 UTC+2 schrieb willem dhaeseleer:

 

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.

they are there to give you an alternative, not a replacement. Callbacks are simple for simpler things. they are the core pattern and they are accepted. every single person new to node, can just use them, as soon she understood async coding style.

it is a very bad habbit to only provide promises api. one of the top3 popular modules on npm is async, which handles callbacks.

So, stop crying about callbacks, learn them and provide a cb-based interface. and stop saying us. :P
 

 

Here are a few of many reasons why to choose promises:

 

- It prevent deep indentation

flatten your code.

- It always you to pass on asynchronous operations

huh?

- 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) ?

you actually type this yourself?

- Refactoring in callback styled code is extremely tedious to the point where it would be almost reasonable to say it's impossible

it always hard to refactor bad written code either with callbacks, promises or even synchronous code.

- Improved readability trough more logical control flow

duh. readability is subjective.

- Integration with coroutines ( you want this )

huh? how is that connected?

 

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 nodejs@googlegroups.com
To unsubscribe from this group, send email to
nodejs+unsubscr...@googlegroups.com
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 nodejs+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
--
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 nodejs@googlegroups.com
To unsubscribe from this group, send email to
nodejs+unsubscr...@googlegroups.com
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 nodejs+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.