Earlier quoted context omitted.
Just to be picky, but I believe you would be better off with this: async function main () { try { const jsons = await Promise.all([ fetch('https://api.github.com/orgs/facebook'), fetch('https://api.github.com/orgs/facebook') ]).map(promise => promise.then(res => res.json())); } catch (err) { console.log(err) } } This way, if one response was much quicker than the other, you could begin sending it through the `res.jso…
Nit -- you want: async function main () { try { const jsons = await Promise.all([ fetch('https://api.github.com/orgs/facebook'), fetch('https://api.github.com/orgs/facebook') ].map(promise => promise.then(res => res.json()))); } catch (err) { console.log(err) } } As written you get "Promise.all(...).map is not a function"
JavaScript async/await implemented in V8
101–110 of 227 posts
Re: JavaScript async/await implemented in V8
#102Earlier quoted context omitted.
> (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…
Just to be picky, but I believe you would be better off with this: async function main () { try { const jsons = await Promise.all([ fetch('https://api.github.com/orgs/facebook'), fetch('https://api.github.com/orgs/facebook') ]).map(promise => promise.then(res => res.json())); } catch (err) { console.log(err) } } This way, if one response was much quicker than the other, you could begin sending it through the `res.jso…
Re: JavaScript async/await implemented in V8
#103Thank you to Microsoft and Anders Hejlsberg for inventing Async/Await (and to F# for the original inspiration) https://en.wikipedia.org/wiki/Futures_and_promises
async/await as we know it actually came from Midori's C# dialect, which indeed was inspired from F#: http://joeduffyblog.com/2015/11/19/asynchronous-everything/ (Although, just to be pedantic, the concept of futures is way older than F#. Alice's syntax, for example, is pretty close)
Re: JavaScript async/await implemented in V8
#104From all my research, I feel like Promises end up making better code than async await. Am I the only one who thinks that? Like, what's the equivalent of Promise.all with async/await? And how do tou do stuff synchronously after kicking off an async process?
I haven't written any async/await code yet, but since it's just sugar over promises, wouldn't you just do "await Promise.all(...)"?
Re: JavaScript async/await implemented in V8
#105Earlier quoted context omitted.
Just to be picky, but I believe you would be better off with this: async function main () { try { const jsons = await Promise.all([ fetch('https://api.github.com/orgs/facebook'), fetch('https://api.github.com/orgs/facebook') ]).map(promise => promise.then(res => res.json())); } catch (err) { console.log(err) } } This way, if one response was much quicker than the other, you could begin sending it through the `res.jso…
Nit -- you want: async function main () { try { const jsons = await Promise.all([ fetch('https://api.github.com/orgs/facebook'), fetch('https://api.github.com/orgs/facebook') ].map(promise => promise.then(res => res.json()))); } catch (err) { console.log(err) } } As written you get "Promise.all(...).map is not a function"
Re: JavaScript async/await implemented in V8
#106Earlier quoted context omitted.
I am willing to admit that async/await is a bridge between the Node and .Net communities -- surmounting this means we are that much closer to literally doubling the developer pool for either sections of the community.
how so? I like the JS async/await a lot, but you couldnt pay me to write .net I personally don't know many devs who would choose to learn a new lang because of a feature (assuming that they didn't want to learn it before it existed)
I came from a language that can do this kind of thing implicitly using coroutines (i.e., I could write imperative code that would pause on a network request and resume afterwards). Have to wade through callback hell -- even with Promises -- was a serious step down.
With async/await being explicit, combined with functionality like Promise.all(), this is actually a better solution than I had before, because I can spawn a dozen queries at once and wait for them all to complete before I continue. I've used that to good advantage already once with an await Promise.all(...) call, and the patterns are so easy to follow that it brings tears to my eyes.
Or I can inject more traditional callbacks when the logic would be easier (or when it would allow several simultaneous calls to complete), which does happen from time to time.
As to whether I'd learn a new language because of it: I'm considering learning Elixir because of even stronger guarantees [1], actually, so yes, I would.
[1] Apparently in addition to being able to write code using light threads like this, you can also put a cap on how long the VM will run code, so if some idiot developer puts a loop in the code that doesn't return control enough, instead of destroying your UI experience it will just pause that loop and resume the main loop. Still have yet to try it though.
Re: JavaScript async/await implemented in V8
#107Earlier quoted context omitted.
Yes. They will be sent into map immediately, and Promise.all() will return a Promise which will settle when the mapped array is all settled (or one errors, but that's not really relevant to the question). We're really just awaiting the promise returned from Promise.all(), but mapping the original fetches into a "new" set of promises.
I'm sorry, but I don't see why/how they would be sent to `map` immediately, given where the parenthesis are in the above code snippet. `Promise.prototype.map` isn't a builtin function is it? If the `map` call was inside the invocation of `Promise.all` then I could see it, but perhaps I am missing something.
Re: JavaScript async/await implemented in V8
#108Earlier quoted context omitted.
Nit -- you want: async function main () { try { const jsons = await Promise.all([ fetch('https://api.github.com/orgs/facebook'), fetch('https://api.github.com/orgs/facebook') ].map(promise => promise.then(res => res.json()))); } catch (err) { console.log(err) } } As written you get "Promise.all(...).map is not a function"
Just to put it out there, an ES6 implementation using async.js would look like async.parallel({ facebook: done => request("https://api.github.com/orgs/facebook", done), twitter: done => request("https://api.github.com/orgs/twitter", done) }, (err, responses) => console.log(err, responses); ); And output something like: null, { facebook: { // facebook data }, twitter: { // twitter data } } Sure it suffers from a third…
Re: JavaScript async/await implemented in V8
#109what'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); //
Re: JavaScript async/await implemented in V8
#110Kinf of OT, but can anyone share their experience about using Babel's async/await in production instead of regular Promises? I'd love to hear about people who have used it in large and complex projects, from a debugging standpoint. As of now, using Bluebird (with its source in a different, blackboxed script), it is possible to follow the code execution through the event loop with async debugging, in a very elegant an…