JavaScript async / await: Mistakes in usage?

Tram Ho

How have you been using Async / await since being introduced by ES7? Or is the code running successfully as satisfactory? We also went through a few examples to see maybe you made a mistake while using Async / await in your code?

1 – What is Async / await?

Async / await introduced by ES7 is an improvement from promise that brings great things in Asynchronous programming with JavaScript. It provides developers js who write synchronous code on asynchonous functions, without interrupting their own code. However, not all developers can use them more effectively and deeply understand the core of their use.

In this article, we will explore the disadvantages of async / await with you when using the wrong case (we may not have fully considered the cases) but the purpose is to help developers use it. They efficiently and accurately use async / await.

2 – Mistake example when using Async / await.

Example 1:

The coder’s task is to find the cat’s owner via the catIDs above.

It’s very simple, but we only talk about async / await. We can be tempted or habitual to do something like this:

What ‘s wrong with the code above We run this code and it all seems to be working properly, without generating bugs.

But here is a problem when using async / await on the above way. The main problem is using async / awai in the for … loop. Specifically, .push in the for loop really brings the problem. Because await in the for-loop is looking for synchronous-looking fetchOwners sequentially. This means we are searching sequentially, find the owner with this id, then search for the owner with a different id and can use parallel. But with async / awai it helps us find owners that don’t depend on other owners and we should replace it with map () (we’ll talk map () about the following fix …).

But in the example above you are acting completely wrong. Although the code above is perfectly valid. But its performance is too bad. I think a lot of devjs still make those mistakes regrettably. What should we do? Of course stop using await in the for-loop, and especially forEach it will cause disastrous mistakes.

In actual code, there are many better ways to use for-loop even if it is synchonous on your code.

To fix the above problem, we should use map (). It seems more appropriate to convert array id to array owner.

This is how we would implement using .map () if the code is synchronized (synchonous).

Because the code above is really synchonous, we can transform an array ID into an array promise (cats’ owners). We can then unpack through Promise.all. as follows

And can rewrite the code more beautifully if you feel .then () is really boring =]].

I think you should instead read this post, instead try to rewrite and test with console.time () to see how effective it is? To help you we have the next example

Example 2: We have the following code:

This function will get all data via authorId.

The above code is not wrong but, it encounters the case as in example 1: await bookModel.fetchAll () must wait until fetchAll () returns. Then await authorModel.fetch (authorId) is called. This is a waste because you will notice that authorModel.fetch (authorId) does not depend on the result of each returned bookModel.fetchAll () but instead they can be called parallel in Promise (). Instead of that we can rewrite the following:


3 – Conclusion:

The async / await keywords introduced by ES7 are definitely an improvement to asynchonous programming in JavaScript. It can make our code easier to read and debug. However, to use them correctly, one must fully understand a lot about Promise (), because they are nothing more than syntax, and basic techniques still Promise () because in fact async / await also returns Give us only one promise (). Hopefully this post can give you some ideas for async / await and can help you prevent some common errors.

Thank you for reading, and if you like this article please comment and share them with other devjs to consider their issues.


Share the news now

Source : Viblo