dotJS 2017 - Wes Bos - Async + Await

[@owaissonija7339]

If you are here from the Odin project, you did great job so far by being persistent. Best of luck ahead!

[@thatmehdude]

feels like the end is still too far man.

[@mridhulml3269]

yoo thank you! really needed that rn.

[@mridhulml3269]

@@thatmehdude yea same...I'm considering jumping to full stack open after skimming through js section

[@AmanSingh-vy5tk]

man lets connect we are not far from each-other in course road, hoping the learning is going good and job is not too far

[@owaissonija7339]

@@AmanSingh-vy5tk send your number/contact

[@alexnezhynsky9707]

Wes Bos delivering top notch quality content, as always 👏

[@XIAOx]

that girl who's laying down there is a mood

[@eiririiii]

i think she is disabled?

[@ajinkyax]

Thanks for showing `await Promise.all(...)` :) @8:03

[@SamuelCarreira]

Great talk! All perfect: great comunication and support slides

[@daniilpanov2194]

I didn't know that Ewan McGregor is an expert in JS. Good for him!

[@stolensentience]

That .find() syntax at 10:59 where you feed it an object… is that a thing? I error out when I try it.

[@DoctorFeral]

I was having breakfast while watching this :)

[@jntlmb]

is this a talk tuah reference?

[@aaron8989]

The parameters within the catchErrors function (req, res, next) are specific parameters to the getOrders function. If I wanted to wrap another function inside catchErrors that took a different set of parameters, would I need to define a new catchErrors function with these parameters inside? Sorry if this is a stupid question but I'm fairly new to coding.

[@YuriPolchenko]

Thanks! Awesome explanation

[@re.liable]

that HOF is like a decorator right?

[@muriukialex]

Great talk!

[@baka_baca]

Awesome talk! Seeing async/await years on after this video was posted, I have a couple of thoughts. I still use the Promise.then quite frequently alongside async/await because it let's me use a point-free style which I find cleaner in many cases. Why bother with a bunch of intermediate variables for data processing when I can cleanly have something like this "fetchData().then(camelCase).then(sendJson(res)).catch(next)". Also async/await is awesome, but I've seen a lot of developers get confused with it and make mistakes they simply wouldn't when using Promise.then. From writing blocking code by using multiple awaits on data calls that don't depend on each other, writing things like this "return await fetchData();" which just isn't necessary, and skipping writing a catch altogether because they think they must use a try/catch block which can be clunky to read and write (i.e. now we have another layer of nesting, sometimes more) instead of using a Promise.catch. Basically, it seems like as soon as developers discover async/await they seem to think they MUST use it in all cases and must never touch a Promise.then or Promise.catch again. I use async/await all the time just like I use Promise.then/catch all the time, I just try to use async/await more sparingly. I use async/await when I'm synchronizing large amounts of custom logic and data calls that won't come out clean with Promise.then. And I use Promise.then when I can nicely write in a point-free style and when I want to make it more clear that I am in fact returning a Promise. I get how async functions automagically wrap the return statement in a Promise for me, but with that detail hidden away I've gotten tripped up, as well as many others, that a Promise is being returned and not what the code says is being returned (i.e. where's the Promise in this line "return { data: formattedData };").

[@stolensentience]

Don’t you have to write .then as a callback i.e. .then(x => x.camelCase)

[@rumax3440]

How to cancel await? You do a network request on button click and then user click it again, which will trigger new event and new await. Would be nice do describe such examples too.

[@bharat9835]

rumax you would probably use throttle/debounce. If you really need cancelling you need to look at rxjs.

[@JeanPatrickSmith]

You can do a faux cancel by having something like: let status = 'good'; and in the response: if something else has happened, if (status === 'bad') > trash/ignore response, cache it, etc... very few cases where you should allow for that to happen. Like bharat said though if you actually need to cancel an async function mid stream, like for big data files or somethinig, than rxjs is your best bet. async/await is good for code readability and what not. In jQuery you can cancel ajax requests mid stream, and same with axios: medium.com/@muehler.v/node-js-meets-opencvs-deep-neural-networks-fun-with-tensorflow-and-caffe-ff8d52a0f072 So, depending on your library you can cancel manually, but async/await doesn't offer that out of the box.

[@WesBos]

A new AbortController() API is here / coming soon to cancel promises

[@raphaelmarot8282]

Thanks!

[@pierread1011]

Still not sold on the async/await thing. It was an interesting talk though, thanks for this!

[@aNotoriousPhD]

opposed to what, .then chaining? Async/await is 10x more readable than .then's and callbacks.

[@Textras]

Syntax.fm

[@lasredchris]

flow control in javascript is hard promise - something that will happen in the future promise.all - wait for all those things to be done come back to it when we have the data what's the deal with then? asyc/await. substute for .then. We don't want to lock up the browser

[@tilakmadichettitheappdeveloper]

when the bus says something, she-up-n-listen

[@wepranaga]

the joke is a sink a weight

[@tadeuasarro]

It took me some time

[@stolensentience]

@@tadeuasarro hadda wait for it to uh, sink in?

[@salwacoding5661]

@@stolensentience Loool That got me laugh more than the original joke.

[@lamme4049]

I'm actually shocked that people think that it's easier to use async/await than normal promises

[@baka_baca]

Agreed, async/await seems like it should be easier glancing at the code, but there's a significant amount of stuff you just have to know and keep in your head while reading and writing it. I use it all the time, but more sparingly than the Promise.then pattern.

[@stolensentience]

@@baka_baca learning curve is higher (arguably) but the readability is too

[@schizo5189]

It just means you don't really understand promise. If you understand promise well, async/await is just syntatic sugar over them. The semantic is not that different

[@Minotauro_di_Chieti]

This is not about async/awais, but axios!!

[@stolensentience]

What.