Well, you are not wrong because this is pretty much a personal preference.
I just do not agree with you. 😎
Hiding async code with syntax sugar
It's not hiding, it's making it clear that it is async.
with async/await you have to wrap stuff in a try/catch
Only if you can handle the error and know what to do, otherwise it is better to let it bubble up.
Lastly, all the possible options you mention although correct, I think they miss the point.
If you have this:
fetch("someapi.com")
.then(foo);
bar();
The point is to refactor into async/await but keep the exact same behaviour.
It does not matter much what that behaviour is on the example (functions don't even have a body here).
My point was that mainly, in real world scenarios, you have to handle errors, so you'll have to write that try/catch at some point. I also shown several scenarios that might be tricky with either approach. Not to mention that is pretty common to forget that as soon as you make a function async, you make it return a Promise as well, even if you're not actually using promises inside, or if you wanted to handle it internally, so is more of a "footgun" than then/catch. Going back to the simplistic example:
fetch("someapi.com").then(foo);bar();
Maybe your intention IS to run both fetch and bar "at the same time", which is quite easy to achieve that way, but if you used await, then running bar at the same time is a little bit more complicated. Not to mention, you can combine async/await with then/catch as well, so is not that we need to chose one OR the other:
awaitfetch("someapi.com").then(foo);bar();
But yeah, as you mentioned, is generally a preference thing. I tend to use async/await only when the then alternative actually is less readable (like with AsyncIterables).
Hey @lukeshiru and @vetras, thanks for sharing your points. I think both ways are completely fine and I also think it depends on personal/team preferences.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Well, you are not wrong because this is pretty much a personal preference.
I just do not agree with you. 😎
Lastly, all the possible options you mention although correct, I think they miss the point.
If you have this:
The point is to refactor into async/await but keep the exact same behaviour.
It does not matter much what that behaviour is on the example (functions don't even have a body here).
Cheers! 🍻 happy coding
My point was that mainly, in real world scenarios, you have to handle errors, so you'll have to write that
try/catchat some point. I also shown several scenarios that might be tricky with either approach. Not to mention that is pretty common to forget that as soon as you make a functionasync, you make it return aPromiseas well, even if you're not actually using promises inside, or if you wanted to handle it internally, so is more of a "footgun" thanthen/catch. Going back to the simplistic example:Maybe your intention IS to run both
fetchandbar"at the same time", which is quite easy to achieve that way, but if you usedawait, then runningbarat the same time is a little bit more complicated. Not to mention, you can combineasync/awaitwiththen/catchas well, so is not that we need to chose one OR the other:But yeah, as you mentioned, is generally a preference thing. I tend to use
async/awaitonly when thethenalternative actually is less readable (like withAsyncIterables).Hey @lukeshiru and @vetras, thanks for sharing your points. I think both ways are completely fine and I also think it depends on personal/team preferences.