NodeJs handles asynchronous methods through async and await

When we write the express backend, we often need to handle a lot of asynchronous IO. In ancient times, we all used the chunk function, which is the function we are most familiar with whose default first parameter is error. Let's simulate the operation of a Mongo database and get a feel for it.

This article mainly introduces how NodeJs handles asynchronous processing through async/await. The content is quite good. Now I share it with you and give you a reference. I hope it can help you.

mongoDb.open(function(err, db){
  if(!err){
    db.collection("users", function(err, collection){
      if(!err){
        let person = {name: "yika", age: 20};
        collection.insert(person, function(err, result){
          if(!err){
            console.log(result);
          }
        });
      }
    })
  }
});

This is what we have criticized callback hell, a bunch of horizontal pyramids. If the callbacks are split into functions, they will become Very fragmented. In order to prevent everyone from being disgusted, I didn't even write about error handling. Normally, every asynchronous operation needs to display or handle its error accordingly.

The Promise Era

Later, we entered a better era of Promise, which we can also call chain operations. Regarding Promise, I have written a series of blog posts before. If you are interested, you can read it back. Let’s take a look at the situation after rewriting the above.

let person = {name: "yika"};
mongoDb
  .open()
  .then(function(database){
   return database.collection("users");
  })
  .then(function(collection){
   return collection.insert(person);
  })
  .then(function(result){
   console.log(result);
  })
  .catch(function(e){
   throw new Error(e);
  })

We can see that we have flattened the pyramid into a linear structure. Compared with the previous chunk function, which was disgusting and difficult to maintain, it has become a promise function, and error handling has become very elegant. But we still cannot ignore certain problems. For example, we must endure that each logic is wrapped up one after another then(). Each function has its own independent scope. If it is necessary to share certain data, It must be hung on the outermost layer. The most important thing is that it is still different from the synchronous programming we are familiar with.

Generator era

Master TJ, through the Generator iterator of ES6, was the first to realize the synchronization function of asynchronous programming, which is the most well-known to uscoLibrary. We can use co(function *(){}) to control the function internally through iterators. And co here acts as a launcher. I have said the same thing about Generator and co in my previous blog post.

let co = require("co");

co(function *(){
  let db, collection, result; 
  let person = {name: "yika"};
  try{
    db = yield mongoDb.open();
    collection = yield db.collection("users");
    result = yield collection.insert(person);
  }catch(e){
    console.error(e.message);
  }
  console.log(result);
});

We are very close to synchronous programming. Within the function wrapped in co, only one asynchronous execution will be completed before the following code will continue to be executed. And error handling is also implemented through try and catch. But what we have to admit is that iterators do not exist for asynchronousness after all. The semantics of yield and * inside do not represent asynchronous function flags. And the iterator needs to be driven by co, which is a little different from the function we imagined.

async/await era

We paid attention to ES7’s async/await, and found that this is what we want! Let’s slightly rewrite the above code.

async function insertData(person){
  let db, collection, result; 
  try{
    db = await mongoDb.open();
    collection = await db.collection("users");
    result = await collection.insert(person);
  }catch(e){
    console.error(e.message);
  }
  console.log(result);
} 

insertData({name: "yika"});

We can see that inserData is a real function that we can call directly without the need for a launcher driver. Of course, internally we can also feel that there is no big difference except that the processing yield has become await. async/await is more in line with the semantics of our asynchronous programming.

Then the question is, how to use it?

Use

We said from the beginning that babel already supports async transform. So just introduce babel when we use it. Of course, the server side and the browser side can have different processing methods. Before we start, we need to introduce the following package. Preset-stage-3 contains the async/await compiled files we need.

$ npm install babel-core --save
$ npm install babel-preset-es2015 --save
$ npm install babel-preset-stage-3 --save

Browser side

Babel originally appeared to enable old browsers to support the new ES6 Features to enhance our development experience. So Babel can be compiled through the babel-cli terminal from the beginning. Or introduce babel files to compile on the browser side. Of course, these are not my most recommended ones, so I’ll just leave them out. In front-end static resource configuration, webpack is currently a better solution. It supports module dependencies of static resources, packaging and merging, and language preprocessing. Of course, here we refer to babel processing.

// webpack.config.js
// 省略上面的文件输入输出的配置，直接看模块加载器的配置
module: {
  loaders: [
    {
      test: /\.js$/,
      exclude: /(node_modules|bower_components)/,
      loader: "babel",
      query: {
       presets: ['es2015', 'stage-3']
      }
    },
  ]
}

So we can use it happily.

Server side

Relatively speaking, the back-end needs to handle much more asynchronous IO than the front-end, and this is also needed more. So how do we introduce babel on the server side?

In fact, the simplest and most troublesome method is to directly compile the js file through babel to create a new file and then use it. Of course, redundant files are inevitable. Out of sight, out of mind, let’s try another method.

We use the officially provided require hook method. As the name suggests, after entering through require, the next files will be processed by Babel when they are required. Because we know that CommonJs is a synchronous module dependency, it is also a feasible method. We need one more js file for startup, a js file that actually executes the program.

// index.js 
// 用于引入babel，并且启动app.js

require("babel-core/register");
require("./app.js");

配置完hook之后，我们就配置babel的.babelrc文件，它是一个json格式的文件。es2015看情况配置，如果是已经是Node5.0版本，就无需再进行编译。

{
 "presets": ["stage-3", "es2015"]
}

最后我们的异步函数代码，写在app.js里即可。

相关推荐：

小程序开发之利用co处理异步流程的实例教程

如何处理异步队列出错？

以jQuery中$.Deferred对象为例讲解promise对象是如何处理异步问题_jquery

The above is the detailed content of NodeJs handles asynchronous methods through async and await. For more information, please follow other related articles on the PHP Chinese website!