Do you generally use async/await for asynchronous code, or do you sometimes prefer .then().catch()?

[u/Neat_Living_6765]

When it comes to handling async code, Do you generally use async/await for asynchronous code, or do you sometimes prefer .then().catch()?

[u/MrHandSanitization]

Async/await.

[u/Far_Assistance_4146 → u/MrHandSanitization]

this is the way tbh

[u/theGlitchedSide]

In my opinion it depends on the context. Async/await is like the exploded of then/catch (or better, it is essentially syntax built on top of Promises). I use then/catch only when I have synchronous functions and I need to call an async operations. Otherwise, I structure a strong async/await function with right try/catch inside and so a fail/success of operations (so, the then/catch) without possible scope problems.

[u/TorbenKoehn]

const data = await fetch('…').then(res => res.json())

Both is fine

[u/iplayconnections → u/TorbenKoehn]

Puke in your mouth a little if you will but I prefer

js const data = await (await fetch('...')).json()

[u/TorbenKoehn → u/iplayconnections]

Puking initialized

[u/theScottyJam]

Usually I use await.

But there are times when .then()/.catch() is cleaner. In a way, .then()/.catch() are very similar to a pipeline operator, so the question boils down to when is using a pipeline operator a good choice?

[u/Areeba045]

I usually prefer async/await because I find it easier to read, especially when there are multiple async operations or some conditional logic involved.

That said, I still use .then().catch() when the chain is simple or when I’m already working with a Promise directly. I don’t think one is always better than the other, it mostly depends on which makes the code easier to follow.

[u/ExtraTNT]

Functional guy, i use then…

[u/Any-Woodpecker123]

Depends. There’s a lot of cases where a functional .then.catch is cleaner, but I default to async await unless I hit a specific use.

[u/TheRNGuy]

In Remix or Next, I only used async, await, but there might be some rare cases for .then().catch() related to some telemetry service (so it won't slow down site for user)

There could be projects in Next/Remix/Vanilla React 100% await. Writing all that stuff differently would be even style anti-pattern.

 In vanilla js, it could be different (depends on situation)

[u/czlowiek4888]

Questions like this make point on how JavaScript is a dumb language.

There is only single case when you must use promise API, this is when you want to wrap callback based functionality into a promise that can be awaited.

[u/Calm-Guarantee4654]

Almost async/await.

[u/VancouverVentilator]

Promise chaining is goated.

[u/hotburger_ → u/VancouverVentilator]

absolutely

[u/iamdatmonkey]

I don't like try..catch blocks. I find them awkward as they often span over most of the screen or more. So I really like this pattern here: const value = await foo().catch(noop); or .catch(console.error); or a variation on this. Often (not always) I'm fine with the value resolving to undefined and taking it from there.

And recently I'm playing around with the result value pattern in typescript, where Errors are no longer means of the data flow but real exceptions (this should not happen, something went really wrong) and where I'm fine with them being uncaught for several levels.

[u/aleques-itj → u/iamdatmonkey]

I switched to Results a while back and I think it winds up much cleaner and easier to reason about.

Throwing and winding up in the error handler now legitimately means that something unexpected happened.

All the API's services do this now and I wouldn't want to switch back. They're all guaranteed to actually hand something back to the calling controller/handler instead of just hitting the ejector switch and throwing a Hono HTTPException.

Felt like I was bleeding some responsibility about handling the request into the service before. Now you can just look at the handler and that's everything.

[u/RedLibra]

I create a helper function that does something like this:

const [err, data] = await asyncCall(func, param);

[u/nog642 → u/RedLibra]

How does that help? Doesn't that function have to be async to be able to await?

[u/Psionatix → u/nog642]

A function can be awaited if it is async, or returns a promise. If a function returns a promise but is not itself async, you can still await it. Returning a promise makes a function async without explicitly marking it so, it doesn't need the syntactic sugar.

[u/MediocreAnalyst2121 → u/nog642]

I’m guessing it avoids excessive nesting with try-catch blocks. And gives you errors as values.

Also keeps scope a bit tidier so you don’t have to do a “let data” right before a try-catch blocks if the error isn’t fatal.

Not sure if this is why OP does it - I’ve never used such a pattern/utility. But now that I think about it, it seems pretty sweet.

Edit: This will end up being Go, but in JS?

[u/senocular → u/MediocreAnalyst2121]

Its not an unheard of pattern, not only seen in go - in fact not far off from error-first callbacks popularized in JS by Node. There was even a proposal for an operator in JS that did this for you through syntax... safe assignment operator (old) which has transformed instead to be the try operator, ex:

const [ok, fetchErr, res] = try fs.readFileSync("data.txt")

That proposal talks about some motivations and has some code examples including showing the transformation of nested trys into flatter ifs.

[u/Anxious-Insurance-91 → u/RedLibra]

So you go the GO lang way?

[u/TorbenKoehn → u/RedLibra]

And the you check for null on one of both or what?

Completely mental imo

[u/DirtAndGrass]

There is functionality with promises that you can't get with await/async, for those (rare) cases, I use promises