New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

es7 async/await #339

Closed
jonathanong opened this Issue Sep 2, 2014 · 10 comments

Comments

7 participants
@jonathanong
Copy link
Member

jonathanong commented Sep 2, 2014

thinking about how koa would work when es7 comes out. ideally, this would work:

app.use(async function (next) {
  // blah
  await next;
  // blah
})

app.use(function* (next) {
  // blah
  yield next;
  // blah
})

goal is to make it backwards compatible. async/await stuff won't be able to do stuff co does like yield []. main issue i'm thinking about is that yield* next would break if the next middleware isn't a generator function, but at least we don't tell people to use yield* next all the time.

i have a dispatcher designed in my mind. i made a pure promise version which is already faster than generators since generators aren't optimized.

@yanickrochon

This comment has been minimized.

Copy link
Contributor

yanickrochon commented Sep 2, 2014

What is the actual status if these implementations? All I can find are drafts from 2013... and most of them do not agree with each other.

@jonathanong

This comment has been minimized.

Copy link
Member

jonathanong commented Sep 2, 2014

they're in the very early stages. however, they're probably going to only allow awaiting promises and it'll return a promise. anything else would probably get too crazy

@ilkkao

This comment has been minimized.

Copy link
Contributor

ilkkao commented Sep 8, 2014

I just listened a Dart presentation from Google. They advertise that all core Dart libraries are async/await ready as they return futures. Upcoming Dart asyn/await will be pretty much identical to ES7 async/await.

Just a random observation that it really is useful to think about this in plain JS too.

(Video: http://video.coldfrontconf.com/9826383/10277729/2ce9909d4cacd76fdcb175ebb16c946c/video_hd/site/why-google-thinks-you-should-drop-video.mp4?uuid=974db842-fc4b-0c98-a49f-ca30ebd1ba9d @ 27:30)

@moimikey

This comment has been minimized.

Copy link

moimikey commented Nov 28, 2014

an inspirational screenshot:

screen shot 2014-11-28 at 12 09 49 pm

@jonathanong

This comment has been minimized.

Copy link
Member

jonathanong commented Dec 18, 2014

https://github.com/koajs/koa/tree/composition if anyone wants to try it. unfortunately it's slower... because of the shimming. hahaha

@yoshuawuyts

This comment has been minimized.

Copy link
Contributor

yoshuawuyts commented Dec 18, 2014

Cool to see how async / await is going to look. From composition:

// async/await functions
stack.push(async function (next) {
  return await Promise.resolve(true);
});

Which is equivalent to:

// async/await functions
stack.push(async function (next) {
  return await fn(val)
});

function fn (val) {
  return Promise.resolve(val)
}
@tj

This comment has been minimized.

Copy link
Member

tj commented Feb 16, 2015

I wonder how that'll work for functions named "async" haha. Might as well drop the function keyword at that point

@dougwilson

This comment has been minimized.

Copy link
Member

dougwilson commented Feb 16, 2015

I think @yoshuawuyts may have swapped the syntax :) it's actually async function () {} (where async comes before the function keyword).

@tj

This comment has been minimized.

Copy link
Member

tj commented Feb 16, 2015

oh right hahah I was going to say, that does nottttt look backwards compatible

@yoshuawuyts

This comment has been minimized.

Copy link
Contributor

yoshuawuyts commented Feb 16, 2015

whoooops, updated to the correct syntax 😸

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment