Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A brief look at async-await

javascript.christmas

Post reply on HN
Print view View original

41–47 of 47 posts

Re: A brief look at async-await

#41

Post by gbuk2013 »

Klathmon wrote: post #32
gbuk2013 wrote: post #28

Earlier quoted context omitted.

I agree with you now that "async/await" is available (as I said in my article that I originally linked to). And thank you for providing a second use case to the one I listed in the article - it paid for all the time I wasted on HN today with this thread. ;) The little bit of magic that makes your code sane is the "await" in front of "Promise.all()" and makes it more elegant than the callback version.

>The little bit of magic that makes your code sane is the "await" in front of "Promise.all()" and makes it more elegant than the callback version. I'd actually say that it's the `Promise.all` that makes it sane, the await could be replaced by a `.then` and be functionally the same. Actually it might be even easier to read to someone who doesn't live and breathe javascript as it will keep the program flowing top-to-bo…

Wow that is ... beautiful. :))

And if the individual functions have the custom error logic inside then a simple ".error(callback)" at the end it will just work.

Re: A brief look at async-await

#42

Post by Klathmon »

nkrisc wrote: post #38
Klathmon wrote: post #16

Earlier quoted context omitted.

you can chain them and avoid the nesting. Anything a .then handler returns becomes the value of the next one like this: fetch(url) .then((response) => response.json()) .then((json) => { // do stuff }) Promises will wait until resolved, normal values will call the next handler "right away" (there's some nuance here and some edge cases about what "right away" means, but for the most part you never need to think about t…

In your last example is `someOtherUserRelatedStuffPromise` on the last line supposed to be `someOtherStuffPromise` from the third line? Either way, there's a very interested construct with promises I didn't realize was possible, but makes sense now that I see it. I never thought about awaiting an initiated promise at any point later on.

Thanks, I fixed the typo.

Re: A brief look at async-await

#43

Post by sosuke »

sloonz wrote: post #36
gherkinnn wrote: post #34

Earlier quoted context omitted.

You’re right of course. But you having the “.” dot one line above made my spine tingle in all the wrong ways. Not that it matters.

The dot one line above is the better style. Change my mind. Pasting check() .then() in node REPL gives : > check() undefined > .then() Invalid REPL keyword Pasting check(). then() Gives the expected result. More generally, Javascript rules about whether a newline constitutes the end of a statement or not are pretty confusing (at least for me), so I prefer using a form that makes it explicit when a statement continues…

I see your perspective but a function call on a line with just the two spaces looks like poor formatting. At a glance it doesn't appear connected to the previous line until I look at the end of that previous line.

My statements end in ; Lines that begin with something other than const or let are likely function calls. If it starts with . then it is connected with the previous line and the statement isn't complete.

But if you're consistent in that style that is all important. Better consistent style in a project than one style over another.

Re: A brief look at async-await

#44

Post by BenoitEssiambre »

hajile wrote: post #37
BenoitEssiambre wrote: post #11

Earlier quoted context omitted.

I agree. Promises solve superficial aesthetic problems that only beginners trip on and unnecessarily add dangerous hidden state and corner cases. You can further simplify that chain() function by removing promises altogether: function chain () { (function loop (i) { if (i > 5) { // set state to failed return; } check((err,result) => { if(err){//set state to failed return;} if (!result) { return loop(i + 1); } // set…

CPS is a very bad idea in JS at present. CPS in scheme works because proper tail call optimization exists, so your call stack doesn't explode. In current JS, the only way to make that work is performing a nextTick or setTimeout on every single function which trashes performance of simple things due to exiting your code back to the event loop all the time. There's a special place in hell reserved for companies that de…

I would also like proper tail call optimization but it's very rare I need to do long loops in CPS style without a call in there that will reset the stack. And in any case, you don't need to call nextTick every iteration. Javascript stacks are over 10000 deep nowadays. If you need performance, call nextTick every 1000 iteration and you will be fine. Note that promises force the stack to be reset all the time and you have no choice to take the performance hit.

Re: A brief look at async-await

#45

Post by mstade »

sloonz wrote: post #36
gherkinnn wrote: post #34

Earlier quoted context omitted.

You’re right of course. But you having the “.” dot one line above made my spine tingle in all the wrong ways. Not that it matters.

The dot one line above is the better style. Change my mind. Pasting check() .then() in node REPL gives : > check() undefined > .then() Invalid REPL keyword Pasting check(). then() Gives the expected result. More generally, Javascript rules about whether a newline constitutes the end of a statement or not are pretty confusing (at least for me), so I prefer using a form that makes it explicit when a statement continues…

I go back and forth on this, I can't make up my own mind let alone change anyone else's!

In any case, I used to do what you do – for pretty much the same reasons – but then I've gone back to starting lines with dot (and ?, ||, &&, and other usual suspects) because I parse code left-to-right, so the presence of such a character tells me that I need to look at the preceding line(s) to get the full picture, and it doesn't so much matter if it makes things paste-friendlier. Without the dot, I've found myself move things around that shouldn't be moved around for example:

    check().
      // Insert stuff here and things break, the lack of dot on the following line had me fooled
      then()
I have no good answers for this, and like I said I go back and forth on this – sometimes in the same file even! I think generally I don't particularly like splitting a statement over multiple line's, but at the same time I like too keep a hard limit of the number of characters I can put on each line. First world programming problem for sure.

Re: A brief look at async-await

#46

Post by gherkinnn »

sloonz wrote: post #36
gherkinnn wrote: post #34

Earlier quoted context omitted.

You’re right of course. But you having the “.” dot one line above made my spine tingle in all the wrong ways. Not that it matters.

The dot one line above is the better style. Change my mind. Pasting check() .then() in node REPL gives : > check() undefined > .then() Invalid REPL keyword Pasting check(). then() Gives the expected result. More generally, Javascript rules about whether a newline constitutes the end of a statement or not are pretty confusing (at least for me), so I prefer using a form that makes it explicit when a statement continues…

> a form that makes it explicit when a statement continues on the next line

I prefer to know that a line is dependent on the previous by having all the dots, pipes, etc on a new line. So I skim the first few characters of every line to see what's happening.

An argument not mentioned here is that having the operator on the new line results in cleaner diffs, as only one line changed. However, I don't care for that and am scared of trailing commas too.

Re: A brief look at async-await

#47

Post by anton96 »

sloonz wrote: post #31

check() .then(result => { if (result) { // set state to finished } check() .then(result => { if (result) { // set state to finished } check() .then(result => { if (result) { // set state to finished } check() .then(result => { if (result) { // set state to finished } check() .then(result => { if (result) { // set state to finished } // set state to not done }) .catch(error => // set state to failed); }) .catch(error…

This is because of tutorials like this that it took me so long to understand promises .
Post reply on HN