談一談幾種處理JavaScript異步操做的辦法

引言

js的異步操做,已是一個老生常談的話題,關於這個話題的文章隨便google一下均可以看到一大堆。那麼爲何我還要寫這篇東西呢?在最近的工做中,爲了編寫一套相對比較複雜的插件,須要處理各類各樣的異步操做。可是爲了體積和兼容性,不打算引入任何的pollyfill,甚至連babel也不容許使用,這也意味着只能以es5的方式去處理。使用回調的方式對於解耦很是不利,因而找了別的方法去處理這個問題。問題是處理完了,卻也引起了本身的一些思考:處理js的異步操做,都有一些什麼方法呢?es6

1、回調函數

傳說中的「callback hell」就是來自回調函數。而回調函數也是最基礎最經常使用的處理js異步操做的辦法。咱們來看一個簡單的例子:設計模式

首先定義三個函數:數組

function fn1 () {
  console.log('Function 1')
}

function fn2 () {
  setTimeout(() => {
    console.log('Function 2')
  }, 500)
}

function fn3 () {
  console.log('Function 3')
}

其中fn2能夠視做一個延遲了500毫秒執行的異步函數。如今我但願能夠依次執行fn1fn2fn3。爲了保證fn3在最後執行,咱們能夠把它做爲fn2的回調函數:瀏覽器

function fn2 (f) {
  setTimeout(() => {
    console.log('Function 2')
    f()
  }, 500)
}

fn2(fn3)

能夠看到,fn2fn3徹底耦合在一塊兒,若是有多個相似的函數,頗有可能會出現fn1(fn2(fn3(fn4(...))))這樣的狀況。回調地獄的壞處我就不贅述了,相信各位讀者必定有本身的體會。babel

2、事件發佈/訂閱

發佈/訂閱模式也是諸多設計模式當中的一種,剛好這種方式能夠在es5下至關優雅地處理異步操做。什麼是發佈/訂閱呢?以上一節的例子來講,fn1fn2fn3均可以視做一個事件的發佈者,只要執行它,就會發佈一個事件。這個時候,咱們能夠經過一個事件的訂閱者去批量訂閱並處理這些事件,包括它們的前後順序。下面咱們基於上一章節的例子,增長一個消息訂閱者的方法(爲了簡單起見,代碼使用了es6的寫法):異步

class AsyncFunArr {
  constructor (...arr) {
    this.funcArr = [...arr]
  }

  next () {
    const fn = this.funcArr.shift()
    if (typeof fn === 'function') fn()
  }

  run () {
    this.next()
  }
}

const asyncFunArr = new AsyncFunArr(fn1, fn2, fn3)

而後在fn1fn2fn3內調用其next()方法:async

function fn1 () {
  console.log('Function 1')
  asyncFunArr.next()
}

function fn2 () {
  setTimeout(() => {
    console.log('Function 2')
    asyncFunArr.next()
  }, 500)
}

function fn3 () {
  console.log('Function 3')
  asyncFunArr.next()
}

// output =>
// Function 1
// Function 2
// Function 3

能夠看到,函數的處理順序等於傳入AsyncFunArr的參數順序。AsyncFunArr在內部維護一個數組,每一次調用next()方法都會按順序推出數組所保存的一個對象並執行,這也是我在實際的工做中比較經常使用的方法。函數

3、Promise

使用Promise的方式,就不須要額外地編寫一個消息訂閱者函數了,只須要異步函數返回一個Promise便可。且看例子:學習

function fn1 () {
  console.log('Function 1')
}

function fn2 () {
  return new Promise((resolve, reject) => {
    setTimeout(() => {
      console.log('Function 2')
      resolve()
    }, 500)
  })
}

function fn3 () {
  console.log('Function 3')
}

一樣的,咱們定義了三個函數,其中fn2是一個返回Promise的異步函數,如今咱們但願按順序執行它們,只須要按如下方式便可:this

fn1()
fn2().then(() => { fn3() })

// output =>
// Function 1
// Function 2
// Function 3

使用Promise與回調有兩個最大的不一樣,第一個是fn2fn3得以解耦;第二是把函數嵌套改成了鏈式調用,不管從語義仍是寫法上都對開發者更加友好。

4、generator

若是說Promise的使用可以化回調爲鏈式,那麼generator的辦法則能夠消滅那一大堆的Promise特徵方法,好比一大堆的then()

function fn1 () {
  console.log('Function 1')
}

function fn2 () {
  setTimeout(() => {
    console.log('Function 2')
    af.next()
  }, 500)
}

function fn3 () {
  console.log('Function 3')
}

function* asyncFunArr (...fn) {
  fn[0]()
  yield fn[1]()
  fn[2]()
}

const af = asyncFunArr(fn1, fn2, fn3)

af.next()

// output =>
// Function 1
// Function 2
// Function 3

在這個例子中,generator函數asyncFunArr()接受一個待執行函數列表fn,異步函數將會經過yield來執行。在異步函數內,經過af.next()激活generator函數的下一步操做。

這麼粗略的看起來,其實和發佈/訂閱模式很是類似,都是經過在異步函數內部主動調用方法,告訴訂閱者去執行下一步操做。可是這種方式仍是不夠優雅,好比說若是有多個異步函數,那麼這個generator函數確定得改寫,並且在語義化的程度來講也有一點不太直觀。

5、優雅的async/await

使用最新版本的Node已經能夠原生支持async/await寫法了,經過各類pollyfill也能在舊的瀏覽器使用。那麼爲何說async/await方法是最優雅的呢?且看代碼:

function fn1 () {
  console.log('Function 1')
}

function fn2 () {
  return new Promise((resolve, reject) => {
    setTimeout(() => {
      console.log('Function 2')
      resolve()
    }, 500)
  })
}

function fn3 () {
  console.log('Function 3')
}

async function asyncFunArr () {
  fn1()
  await fn2()
  fn3()
}

asyncFunArr()

// output =>
// Function 1
// Function 2
// Function 3

有沒有發現,在定義異步函數fn2的時候,其內容和前文使用Promise的時候如出一轍?再看執行函數asyncFunArr(),其執行的方式和使用generator的時候也很是相似。

異步的操做都返回Promise,須要順序執行時只須要await相應的函數便可,這種方式在語義化方面很是友好,對於代碼的維護也很簡單——只須要返回Promise並await它就好,無需像generator那般須要本身去維護內部yield的執行。

6、尾聲

做爲一個概括和總結,本文內容的諸多知識點也是來自於他人的經驗,不過加入了一些本身的理解和體會。不求科普於他人,但求做爲我的的積累。但願讀者能夠提出訂正的意見,共同窗習進步!

相關文章
相關標籤/搜索