loading...

Async + Await refactor, which do you like best?

wilburpowery profile image Wilbur Powery ・1 min read

Discussion

pic
Editor guide
Collapse
avalander profile image
Avalander

I don't think that async/await is a bad thing, but I like that Promises force you to think what parts of your code depend on which asynchronous data and to organise it accordingly. Async/await allows you to write asynchronous code like it is synchronous and I have mixed feelings about this.

It's worth mentioning that I don't use either, I usually use Fluture because it doesn't automagically catch all and every error in the rejection branch, which you can't achieve with async/await or Promises. But the Fluture API is quite similar to a Promise and I kind of like it.

Also, notice that if the goal is to remove indentation, there is no reason why the last then of the example on the left can't be rewritten as

.then(response => {
    this.updateEventValues()
    return this.Alert.success('Se ha actualizado el evento')
)
.then(() => this.clearEventAndClose())

Which has the additional benefit that if you need to catch any rejection, you only need to do it once.

Collapse
ben profile image
Ben Halpern

I agree with this logic

Collapse
lietux profile image
Janne "Lietu" Enberg

Neither is very good, as you're doing nothing to handle errors.

One requires .catch() in several places, the other a try { ... } catch (...) { ... } block or several.

Overall the await syntax is much easier to read and follow the logic, but if you have to put a try..catch around every one it quickly becomes a mess too.

Collapse
qm3ster profile image
Mihail Malo

I often do the following:

await fallible().catch(errorHandler)

It allows me to pipe/sidechain my errors where they truly belong, instead of breaking up my happy path logic with inline implementation of the catch block OR lambda.
If I need to abort the current function, the handler will just rethrow.

Collapse
wilburpowery profile image
Wilbur Powery Author

Yeah, I agree. As with everything, you should choose carefully 😄

Collapse
tailcall profile image
Anton Istomin

I love async/await and and the same time I despise try/catch, so I tend to use .catch() method for error handling. Just looks neater. I wish I could do all exception handling that way.

Collapse
xtofl profile image
xtofl

i think, as a matter of fact, that you can do all error handling this way. The functional programming folks found that out and called the resulting pattern a Monad. Take a look at m.youtube.com/watch?v=Mw_Jnn_Y5iA#

Collapse
buinauskas profile image
Evaldas

This is totally out of topic, but what font is this?

Collapse
wilburpowery profile image
Wilbur Powery Author

Operator Mono 😊

Collapse
qm3ster profile image
Mihail Malo

HAHAHA they asked you this on twitter as well :v

Collapse
qm3ster profile image
Mihail Malo

I think the async/await is a clear winner here, since these were 4 sequential operations, 2 of which just needed to yield yet still block the progress of this function, and cancel the function if they throw.
It's the textbook happy case for async/await.

I do agree with @avalander 's refactor though, which gets you closer to this without the async syntax.

Collapse
p250 profile image
01101001

i like async and await. Especially await :))

Collapse
asparallel profile image
AsParallel

Async await is cool, but I've definitely come to prefer Rx.Observable.fromPromise. That'll certainly flatten your then sequence.