question: how to async with co

[yoshuawuyts]

Sometimes generators confuse the soul out of my body and I definitely don't want to be above asking help, so here goes:

How do you yield in co, within a callback without having the call stack unwrap itself. Also: how do you yield from a callback; passing in a generatorFunction directly stuff breaks.

This is the function I'm trying to make work:

function *xhrmw(next) {
  if (!this.url) return yield next;

  var opts = {
    url: this.url + qs.stringify(this.query),
    body: this.body,
    method: this.method,
    headers: this.headers
  };

  xhr(opts, function(err, res, body) {
    if (err) this.throw(err);
    this.response = res;
    this.body = body;
    // <needs a yield, cannot yield, because not a generator function>
  }.bind(this));
}

[tj]

can't yield from within that callback, you'd have to change xhr to return something yield-able instead of using a callback. Generators only let you suspend within the generator function itself

[yoshuawuyts]

That was the one answer I was hoping I wouldn't get, haha. Thanks for the reply though, I'll probably have to write a custom xhr module / talk it over with @Raynos (:

[rickharrison]

@yoshuawuyts You can always just wrap your xhr module in a thunk or a promise. Then you can yield that.

[yoshuawuyts]

@rickharrison what would that look like? Tried fumbling around with thunkify but couldn't get it quite right.

[rickharrison]

function makeRequest() {
  // do work

  return function (done) {
    done(null, returnValue);
  }
}

yield makeRequest()

Or a promise example which might be easier to understand

var promise = new Promise(function (resolve, reject) {
  xhr(opts, function(err, res) {
    if (err) return reject(err);

    resolve(res);
  });
});

yield promise();

[yoshuawuyts]

@rickharrison Thanks! I was wondering though: where does returnValue come from in the first example?

edit: to clarify, we're doing an xhr request here so doing something synchronous won't cut it :(

[Raynos]

@yoshuawuyts

function *xhrmw(next) {
  if (!this.url) return yield next;

  var opts = {
    url: this.url + qs.stringify(this.query),
    body: this.body,
    method: this.method,
    headers: this.headers
  };

  var thunk = xhr.bind(null, opts);
  var response = yield thunk;
  this.response = response;
  this.body = response.body;
  // <needs a yield>
}

[Raynos]

@yoshuawuyts

Converting from callback to thunk is trivial just var thunk = doAsyncThing.bind(null, arg). Thunk is now a function of one argument, a callback argument. Which is a thunk by definition.

This means you can now yield on it. I do this everywhere when I do generators. This allows for a single async function definition that works with node, npm & plain callbacks but is also usable from within generators.

[yoshuawuyts]

@Raynos This is just wonderful, thank you so much!

[Fishrock123]

@Raynos does that have any benefits / drawbacks compared to this kind of thunk? https://github.com/repo-utils/org-labels/blob/master/bin/_org-labels#L93-L105

[navaru]

@Fishrock123 as a drawback .bind will be slower than closure format if you care about micro-optimizations

http://stackoverflow.com/questions/8656106/why-is-function-prototype-bind-slow

[Raynos]

@Fishrock123 I use .bind() because its the most convenient and minimal change at the callsite (i.e. the user of the function ) to support generators.

This puts zero burden on the author of the module and minimal burden on the user of the module in generators.

[yanickrochon]

As an alternative, I have written a module to handle this sort of pattern.

function *xhrmw(next) {
  if (!this.url) return yield next;

  var marker = suspend();
  var opts = {
    url: this.url + qs.stringify(this.query),
    body: this.body,
    method: this.method,
    headers: this.headers
  };

  xhr(opts, function(err, res, body) {
    if (err) this.throw(err);
    this.response = res;
    marker.resume(err, body);
  }.bind(this));

  this.body = yield marker.wait();
}

Shameless plug :)

[yoshuawuyts]

Something that may not be apparent is that using the .bind() method the result is an array of responses. This, to me, is pretty crazy (and useful).

edit: I might be totally wrong about this one though, this behavior might be xhr specific. Generators are still weird to me, haha.

[Raynos]

@yoshuawuyts an array of argument is just co being "special" ( https://github.com/tj/co/blob/master/index.js#L59-L60 ).

[yoshuawuyts]

Woah, this somehow feels a bit like golang with the multiple response assignments. It's a shame that the err, res, body pattern from xhr isn't preserved though.

[arxpoetica]

@Raynos I've looked for documentation about this nature of .bind()thunk-like behavior, and can't find it—you're definitely right, it works that way—but I'd like to understand the internals a little better. Can you (or anyone) point me in the right direction?