So I've been reading about the usage of the co library, and the general design pattern I've seen in most blog posts is wrapping functions that have callbacks in thunks. Then using an es6 generator to yield those thunks to the co object. Like this:

co(function *(){
  var a = yield read(‘Readme.md’);
  var b = yield read(‘package.json’);
  console.log(a);
  console.log(b);
});
function read(path) {
  return function(done){
    fs.readFile(path, ‘utf8', done);
  }
}

And that I can understand because it brings all the benefits of promises like better readability and better error handling.

But what's the point of using co if you already have promises available?

co(function* () {
  var res = yield [
    Promise.resolve(1),
    Promise.resolve(2),
    Promise.resolve(3),
  ];
  console.log(res); // => [1, 2, 3]
}).catch(onerror);

Why not something like

Promise.all([
  Promise.resolve(1),
  Promise.resolve(2),
  Promise.resolve(3),
]).then((res) => console.log(res)); // => [1, 2, 3]
}).catch(onerror);

To me, co makes the code look more confusing pared to the Promise version.

So I've been reading about the usage of the co library, and the general design pattern I've seen in most blog posts is wrapping functions that have callbacks in thunks. Then using an es6 generator to yield those thunks to the co object. Like this:

co(function *(){
  var a = yield read(‘Readme.md’);
  var b = yield read(‘package.json’);
  console.log(a);
  console.log(b);
});
function read(path) {
  return function(done){
    fs.readFile(path, ‘utf8', done);
  }
}

And that I can understand because it brings all the benefits of promises like better readability and better error handling.

But what's the point of using co if you already have promises available?

co(function* () {
  var res = yield [
    Promise.resolve(1),
    Promise.resolve(2),
    Promise.resolve(3),
  ];
  console.log(res); // => [1, 2, 3]
}).catch(onerror);

Why not something like

Promise.all([
  Promise.resolve(1),
  Promise.resolve(2),
  Promise.resolve(3),
]).then((res) => console.log(res)); // => [1, 2, 3]
}).catch(onerror);

To me, co makes the code look more confusing pared to the Promise version.

• javascript
• node.js
• promise
• async-await
• thunk

Share Improve this question Follow edited Mar 31, 2016 at 20:57 Filip Dupanović 33.7k1414 gold badges8989 silver badges119119 bronze badges asked Jan 5, 2016 at 21:54 m0menim0meni 16.5k1818 gold badges8787 silver badges148148 bronze badges 4

• 2 I haven't found any cases (ignoring es7) where it makes sense to me to use generators with promises. Most of the examples i've seen just make it more plicated just so that they can use generators. – Kevin B Commented Jan 5, 2016 at 21:57
• co has it's uses, doesn't mean you use it everywhere even if it's not appropriate! – Jaromanda X Commented Jan 5, 2016 at 21:59
• @KevinB for the es7 features are you referring to async/await or is there something else? – m0meni Commented Jan 5, 2016 at 21:59
• 2 referring to async/await, it does allow for some cool things. – Kevin B Commented Jan 5, 2016 at 22:00

Add a ment  | 

1 Answer 1

Sorted by: Reset to default 8

No real cases, no. Unless you really hate the promise constructor (in which case, bluebird promisify to the rescue).

When you have Promises natively, nearly all valid usecases for callbacks that are called once with a single value are effectively moot.