用訊號來控制非同步流程

發表於2017-08-08

我們知道,JavaScript 不管是操作 DOM,還是執行服務端任務,不可避免需要處理許多非同步呼叫。在早期,許多開發者僅僅通過 JavaScript 的回撥方式來處理非同步,但是那樣很容易造成非同步回撥的巢狀,產生 “Callback Hell”。

後來,一些開發者使用了 Promise 思想來避免非同步回撥的巢狀,社群將根據思想提出 Promise/A+ 規範,最終,在 ES6 中內建實現了 Promise 類,隨後又基於 Promise 類在 ES2017 裡實現了 async/await,形成了現在非常簡潔的非同步處理方式。

比如 thinkJS 下面這段程式碼就是典型的 async/await 用法,它看起來和同步的寫法完全一樣,只是增加了 async/await 關鍵字。

async/await 可以算是一種語法糖,它將

轉換成了

有了 async,await,可以寫出原來很難寫出的非常簡單直觀的程式碼:

JS Bin on jsbin.com

上面的程式碼中,我們利用非同步的 setTimeout 實現了一個 idle 的非同步方法,返回 promise。許多非同步處理過程都能讓它們返回 promise,從而產生更簡單直觀的程式碼。

網頁中的 JavaScript 還有一個問題,就是我們要響應很多非同步事件,表示使用者操作的非同步事件其實不太好改寫成 promise,事件代表控制,它和資料與流程往往是兩個層面的事情,所以許多現代框架和庫通過繫結機制把這一塊封裝起來,讓開發者能夠聚焦於運算元據和狀態,從而避免增加系統的複雜度。

比如上面那個“交通燈”,這樣寫已經是很簡單,但是如果我們要增加幾個“開關”,表示“暫停/繼續“和”開啟/關閉”,要怎麼做呢?如果我們還想要增加開關,人工控制和切換燈的轉換,又該怎麼實現呢?

有同學想到這裡,可能覺得,哎呀這太麻煩了,用 async/await 搞不定,還是用之前傳統的方式去實現吧。

其實即使用“傳統”的思路,要實現這樣的非同步狀態控制也還是挺麻煩的,但是我們的 PM 其實也經常會有這樣麻煩的需求。

我們試著來實現一下:

JS Bin on jsbin.com

上面這麼做實現了控制交通燈的開啟關閉。但是實際上這樣的程式碼讓 onoffButton、 idelCtrl 和 traffic 各種耦合,有點慘不忍睹……

這還只是最簡單的“開啟/關閉”,“暫停/繼續”要比這個更復雜,還有使用者自己控制燈的切換呢,想想都頭大!

在這種情況下,因為我們把控制和狀態混合在一起,所以程式邏輯不可避免地複雜了。這種複雜度與 callback 和 async/await 無關。async/await 只能改變程式的結構,並不能改變內在邏輯的複雜性。

那麼我們該怎麼做呢?這裡我們就要換一種思路,讓訊號(Signal)登場了!看下面的例子:

JS Bin on jsbin.com

我們對程式碼進行一些修改,封裝一個 TrafficSignal,讓 onoffButton 只控制 traficSignal 的狀態。這裡我們用一個簡單的 Signal 庫,它可以實現狀態和控制流的分離,例如:

JS Bin on jsbin.com

有同學說,這樣寫程式碼也不簡單啊,程式碼量比上面寫法還要多。的確這樣寫程式碼量是比較多的,但是它結構清晰,耦合度低,可以很容易擴充套件,比如:

JS Bin on jsbin.com

Signal 非常適合於事件控制的場合,再舉一個更簡單的例子,如果我們用一個按鈕控制簡單的動畫的暫停和執行,可以這樣寫:

JS Bin on jsbin.com

總結

我們可以用 Signal 來控制非同步流程,它最大的作用是將狀態和控制分離,我們只需要改變 Signal 的狀態,就可以控制非同步流程,Signal 支援 until 和 while 謂詞,來控制狀態的改變。

可以在 GitHub repo 上進一步瞭解關於 Signal 的詳細資訊。

相關文章