{"id":378,"date":"2018-06-14T22:49:41","date_gmt":"2018-06-14T22:49:41","guid":{"rendered":"https:\/\/blog.hassler.ec\/wp\/?p=378"},"modified":"2018-06-14T22:49:41","modified_gmt":"2018-06-14T22:49:41","slug":"javascript-async-await-the-good-part-pitfalls-and-how-to-use","status":"publish","type":"post","link":"https:\/\/blog.hassler.ec\/wp\/2018\/06\/14\/javascript-async-await-the-good-part-pitfalls-and-how-to-use\/","title":{"rendered":"JavaScript async\/await: The Good Part, Pitfalls and How to\u00a0Use"},"content":{"rendered":"
\n
\n
\n
\n
\n
<\/div>\n
<\/canvas><\/div>\n<\/div>\n<\/figure>\n

The\u00a0async\/await<\/code>\u00a0introduced by ES7 is a fantastic improvement in asynchronous programming with JavaScript. It provided an option of using synchronous style code to access resoruces asynchronously, without blocking the main thread. However it is a bit tricky to use it well. In this article we will explore async\/await from different perspectives, and will show how to use them correctly and effectively.<\/p>\n

The good part in async\/await<\/h3>\n

The most important benefit\u00a0async\/await<\/code>\u00a0brought to us is the synchronous programming style. Let\u2019s see an example.<\/p>\n

\/\/ async\/await\r\nasync getBooksByAuthorWithAwait(authorId) {\r\n  const books = await bookModel.fetchAll();\r\n  return books.filter(b => b.authorId === authorId);\r\n}<\/pre>\n
\/\/ promise\r\ngetBooksByAuthorWithPromise(authorId) {\r\n  return bookModel.fetchAll()\r\n    .then(books => books.filter(b => b.authorId === authorId));\r\n}<\/pre>\n
It is obvious that the\u00a0async\/await<\/code>version is way easier understanding than the promise version. If you ignore the\u00a0await<\/code>\u00a0keyword, the code just looks like any other synchronous languages such as Python.<\/p>\n
And the sweet spot is not only readability.\u00a0async\/await<\/code>\u00a0has native browser support. As of today, all the mainstream browsers have full support to async functions.<\/p>\n
\n
\n
<\/div>\n
<\/canvas><\/div>\n<\/div>
All mainstream browsers support Async functions. (Source:\u00a0https:\/\/caniuse.com\/<\/a>)<\/figcaption><\/figure>\n
Native support means you don\u2019t have to\u00a0transpile<\/a>\u00a0the code. More importantly, it facilitates debugging. When you set a breakpoint at the function entry point and step over the\u00a0await<\/code>\u00a0line, you will see the debugger halt for a short while while\u00a0bookModel.fetchAll()<\/code>\u00a0doing its job, then it moves to the next\u00a0.filter<\/code>line! This is much easier than the promise case, in which you have to setup another breakpoint on the\u00a0.filter<\/code>\u00a0line.<\/p>\n
\n
\n
<\/div>\n
<\/canvas><\/div>\n<\/div>
Debugging async function. Debugger will wait at the await line and move to the next on resolved.<\/figcaption><\/figure>\n
Another less obvious benefit is the\u00a0async<\/code>\u00a0keyword. It declares that the\u00a0getBooksByAuthorWithAwait()<\/code>\u00a0function return value is guaranteed to be a promise, so that callers can call\u00a0getBooksByAuthorWithAwait().then(...)<\/code>\u00a0or\u00a0await getBooksByAuthorWithAwait()<\/code>\u00a0safely. Think about this case (bad practice!):<\/p>\n
getBooksByAuthorWithPromise(authorId) {\r\n  if (!authorId) {\r\n    return null;\r\n  }\r\n  return bookModel.fetchAll()\r\n    .then(books => books.filter(b => b.authorId === authorId));\r\n  }\r\n}<\/pre>\n
In above code,\u00a0getBooksByAuthorWithPromise<\/code>\u00a0may return a promise (normal case) or a\u00a0null<\/code>\u00a0value (exceptional case), in which case caller cannot call\u00a0.then()<\/code>\u00a0safely. With\u00a0async<\/code>\u00a0declaration, it becomes impossible for this kind of code.<\/p>\n
Async\/await Could Be Misleading<\/h3>\n
Some articles compare async\/await with Promise and claim it is the next generation in the evolution of JavaScript asynchronous programming, which I respectfully disagree. Async\/await IS an improvement, but it is no more than a syntactic sugar, which will not change our programming style completely.<\/p>\n
Essentially, async functions are still promises. You have to understand promises before you can use async functions correctly, and even worse, most of the time you need to use promises along with async functions.<\/span><\/p>\n
Consider the\u00a0getBooksByAuthorWithAwait()<\/code>\u00a0and\u00a0getBooksByAuthorWithPromises()<\/code>\u00a0functions in above example. Note that they are not only identical functionally, they also have exactly the same interface!<\/p>\n
This means\u00a0getBooksByAuthorWithAwait()<\/code>\u00a0will return a promise if you call it directly.<\/p>\n
Well, this is not necessarily a bad thing. Only the name\u00a0await<\/code>\u00a0gives people a feeling that \u201cOh great this can convert asynchronous functions to synchronous functions\u201d which is actually wrong.<\/p>\n
Async\/await Pitfalls<\/h3>\n
So what mistakes may be made when using\u00a0async\/await<\/code>? Here are some common ones.<\/p>\n
Too Sequential<\/h4>\n
Although\u00a0await<\/code>\u00a0can make your code look like synchronous, keep in mind that they are still asynchronous and care must be taken to avoid being too sequential.<\/p>\n
async getBooksAndAuthor(authorId) {\r\n  const books = await bookModel.fetchAll();\r\n  const author = await authorModel.fetch(authorId);\r\n  return {\r\n    author,\r\n    books: books.filter(book => book.authorId === authorId),\r\n  };\r\n}<\/pre>\n
This code looks logically correct. However this is wrong.<\/p>\n
    \n
  1. await bookModel.fetchAll()<\/code>\u00a0will wait until\u00a0fetchAll()<\/code>\u00a0returns.<\/li>\n
  2. Then\u00a0await authorModel.fetch(authorId)<\/code>\u00a0will be called.<\/li>\n<\/ol>\n
    Notice that\u00a0authorModel.fetch(authorId)<\/code>\u00a0does not depend on the result of\u00a0bookModel.fetchAll()<\/code>\u00a0and in fact they can be called in parallel! However by using\u00a0await<\/code>\u00a0here these two calls become sequential and the total execution time will be much longer than the parallel version.<\/p>\n
    Here is the correct way:<\/p>\n
    async getBooksAndAuthor(authorId) {\r\n  const bookPromise = bookModel.fetchAll();\r\n  const authorPromise = authorModel.fetch(authorId);\r\n  const book = await bookPromise;\r\n  const author = await authorPromise;\r\n  return {\r\n    author,\r\n    books: books.filter(book => book.authorId === authorId),\r\n  };\r\n}<\/pre>\n
    Or even worse, if you want to fetch a list of items one by one, you have to rely on promises:<\/p>\n
    async getAuthors(authorIds) {\r\n  \/\/ WRONG, this will cause sequential calls\r\n  \/\/ const authors = _.map(\r\n  \/\/   authorIds,\r\n  \/\/   id => await authorModel.fetch(id));<\/pre>\n
    \/\/ CORRECT\r\n  const promises = _.map(authorIds, id => authorModel.fetch(id));\r\n  const authors = await Promise.all(promises);\r\n}<\/pre>\n
    In short, you still need to think about the workflows asynchronously, then try to write code synchronously with\u00a0await<\/code>. In complicated workflow it might be easier to use promises directly.<\/p>\n
    Error Handling<\/h3>\n
    With promises, an async function have two possible return values: resolved value, and rejected value. And we can use\u00a0.then()<\/code>\u00a0for normal case and\u00a0.catch()<\/code>\u00a0for exceptional case. However with\u00a0async\/await<\/code>\u00a0error handling could be tricky.<\/p>\n
    try\u2026catch<\/h4>\n
    The most standard (and my recommended) way is to use\u00a0try...catch<\/code>statement. When\u00a0await<\/code>\u00a0a call, any rejected value will be thrown as an exception. Here is an example:<\/p>\n
    class BookModel {\r\n  fetchAll() {\r\n    return new Promise((resolve, reject) => {\r\n      window.setTimeout(() => { reject({'error': 400}) }, 1000);\r\n    });\r\n  }\r\n}<\/pre>\n
    \/\/ async\/await\r\nasync getBooksByAuthorWithAwait(authorId) {\r\ntry {\r\n  const books = await bookModel.fetchAll();\r\n} catch (error) {\r\n  console.log(error);    \/\/ { \"error\": 400 }\r\n}<\/pre>\n
    The\u00a0catch<\/code>ed error is exactly the rejected value. After we caught the exception, we have several ways to deal with it:<\/p>\n