Discussion on: Async without await

[Israel Tiomno]

Thanks for the article Luka, I agree with your examples. Actually, I have a rule on my IDE that warms me of unnecessary await in the return statement.

What's your opinion about this other snippet that I see utterly pointless? Why would you add the async keyword in such a case?

async function asyncCall() {
  return new Promise((resolve, reject) => {
    // Some fancy code here calling resolve() and reject()
  });
}

[Luka Vidaković]

Hey Israel! I believe that this one would go even more into the area of personal and team preferences. I tend to use async in places like services, and similar groups of code that tend to grow in complexity, to have a clear indication of how the code inside the function behaves. Another reason I do that is that I don't want to change the function "signature" if function becomes more complex and I decide to add the await mechanism later on. That way commits are a bit cleaner. Whereas in a case when you add the "async" keyword within a commit, you can't immediately tell if the function was already async until you look at the code inside it(code reviews).

Your example code makes it pretty obvious that it's an async function(even without the async keyword) I agree. But depending on the complexity of this particular part of the code, new Promise(... code block will sometimes move to a utility or service of some kind and it might no longer be obvious that this outer function is in fact async, depending on the naming of the used function/service. At least in a bit more complex parts of the code, so that's the use case I'd find this fairly legitimate to do. We could argue that with this approach you are basically preparing your code for future changes that might not happen.

My approach is to use async in places where I think the function will contain more than a few lines of code, will use external services, or in some often used functions where I want to clearly indicate that it's an async function. That usually leaves me with a cleaner git change history later on and saves me a bit of time by being more obvious than relying on the readability of the code inside the function or the function name.

Most of this boils down to personal preference. But I'd argue that having strict lint rules regarding an "async" keyword is a pain in the neck most of the time and doesn't really contribute to readability or the quality of code. Maybe I'm wrong.

Hopefully, I managed to make myself a bit clearer here 😅

[Israel Tiomno]

Thanks for the answer, Luka! Fair enough! :)
This construction makes sense to me now after getting your point and will probably follow that approach in the future. 👍