JavaScript async/await implemented in V8

Post by grandalf » Tue, May 17, 2016, 4:11 AM UTC

jeswin wrote: post #51

avodonosov wrote: post #30

what's the point of explicitly declaring functions "async", and then explicitly saying "await". IMHO all this could be done automatically by language.

Because you don't always have to await a function, and it isn't always possible for the runtime or language to decide whether to "await" or not. /* The following code may or may not use an await. Not await-ing would be better user experience. */ async function sendEmails(id) { ... } async function signUp(userData) { const user = await db.saveUser(userData); sendEmails(user.id); //

Post by ludamad » Tue, May 17, 2016, 4:18 AM UTC

dvlsg wrote: post #25

startling wrote: post #7

Earlier quoted context omitted.

Is the syntax composable? Can I do const json = await (await fetch(https://api.github.com/orgs/facebook')).json(); or do I have to name it?

You probably can, but you may as well just do this instead: const json = await fetch('https://api.github.com/orgs/facebook').then(res => res.json());

Post by laichzeit0 » Tue, May 17, 2016, 4:20 AM UTC

norman784 wrote: post #22

andrewstuart2 wrote: post #15

I have yet to see a convincing argument that this feature is necessary or even helpful beyond one-liners. The Q promises API, to me, is the right way to reason about asynchrony. Once you understand closures and first class functions, so much about complex asynchronous flows (e.g. multiple concurrent calls via Q.all, multiple "returns" via callback arguments) become so simple. The "tons of libraries" argument doesn't…

The think about using async/await its to write less code, make it much simple and makes also easy to try/catch errors. The think I don't like about promises its that you need to write a lot of lines that you could avoid with async/await, i.e: new Promise(function(success, failure){ db.fetch('sql...', function(err, data){ if (err) failure(err) else success(data) }) }) VS var data = await db.fetch('sql...') Also if you…

Post by sodatea » Tue, May 17, 2016, 4:34 AM UTC

johnhenry wrote: post #79

I'm definitely rooting for the feature to be included in the spec as soon as possible, but I'm a little weary when features are added to the engine before being standardized. Object.observe, anyone?

Post by andrewstuart2 » Tue, May 17, 2016, 4:37 AM UTC

tanto wrote: post #16

andrewstuart2 wrote: post #15

I have yet to see a convincing argument that this feature is necessary or even helpful beyond one-liners. The Q promises API, to me, is the right way to reason about asynchrony. Once you understand closures and first class functions, so much about complex asynchronous flows (e.g. multiple concurrent calls via Q.all, multiple "returns" via callback arguments) become so simple. The "tons of libraries" argument doesn't…

> (e.g. multiple concurrent calls via Q.all, multiple "returns" via callback arguments) How about: async function main () { try { const responses = await Promise.all([ fetch('https://api.github.com/orgs/facebook'), fetch('https://api.github.com/orgs/facebook') ]); const jsons = await Promise.all(responses.map(res => res.json())) } catch (err) { console.log(err) } } I think this is pretty clear and not needing any lib…