前端框架的數(shù)據(jù)流
前端框架實現(xiàn)了數(shù)據(jù)驅(qū)動視圖變化的功能，我們用 template 或者 jsx 描述好了數(shù)據(jù)和視圖的綁定關系，然后就只需要關心數(shù)據(jù)的管理了。
數(shù)據(jù)在組件和組件之間、組件和全局 store 之間傳遞，叫做前端框架的數(shù)據(jù)流。
一般來說，除了某部分狀態(tài)數(shù)據(jù)是只有某個組件關心的，我們會把狀態(tài)數(shù)據(jù)放在組件內(nèi)以外，業(yè)務數(shù)據(jù)、多個組件關心的狀態(tài)數(shù)據(jù)都會放在 store 里面。組件從 store 中取數(shù)據(jù)，當交互的時候去通知 store 改變對應的數(shù)據(jù)。
這個 store 不一定是 redux、mobox 這些第三方庫，其實 react 內(nèi)置的 context 也可以作為 store。但是 context 做為 store 有一個問題，任何組件都能從 context 中取出數(shù)據(jù)來修改，那么當排查問題的時候就特別困難，因為并不知道是哪個組件把數(shù)據(jù)改壞的，也就是數(shù)據(jù)流不清晰。
正是因為這個原因，我們幾乎見不到用 context 作為 store，基本都是搭配一個 redux。
所以為什么 redux 好呢?第一個原因就是數(shù)據(jù)流清晰，改變數(shù)據(jù)有統(tǒng)一的入口。
組件里都是通過 dispatch 一個 action 來觸發(fā) store 的修改，而且修改的邏輯都是在 reducer 里面，組件再監(jiān)聽 store 的數(shù)據(jù)變化，從中取出最新的數(shù)據(jù)。
這樣數(shù)據(jù)流動是單向的，清晰的，很容易管理。
這就像為什么我們在公司里想要什么權限都要走審批流，而不是直接找某人，一樣的道理。集中管理流程比較清晰，而且還可以追溯。
異步過程的管理
很多情況下改變 store 數(shù)據(jù)都是一個異步的過程，比如等待網(wǎng)絡請求返回數(shù)據(jù)、定時改變數(shù)據(jù)、等待某個事件來改變數(shù)據(jù)等，那這些異步過程的代碼放在哪里呢?
組件?
放在組件里是可以，但是異步過程怎么跨組件復用?多個異步過程之間怎么做串行、并行等控制?
所以當異步過程比較多，而且異步過程與異步過程之間也不獨立，有串行、并行、甚至更復雜的關系的時候，直接把異步邏輯放組件內(nèi)不行。
不放組件內(nèi)，那放哪呢?
redux 提供的中間件機制是不是可以用來放這些異步過程呢?
redux 中間件
先看下什么是 redux 中間件：
redux 的流程很簡單，就是 dispatch 一個 action 到 store， reducer 來處理 action。那么如果想在到達 store 之前多做一些處理呢?在哪里加?
改造 dispatch!中間件的原理就是層層包裝 dispatch。
下面是 applyMiddleware 的源碼，可以看到 applyMiddleware 就是對 store.dispatch 做了層層包裝，最后返回修改了 dispatch 之后的 store。
- functionapplyMiddleware(middlewares){
- letdispatch=store.dispatch
- middlewares.forEach(middleware=>
- dispatch=middleware(store)(dispatch)
- )
- return{...store,dispatch}
- }
所以說中間件最終返回的函數(shù)就是處理 action 的 dispatch：
- functionmiddlewareXxx(store){
- returnfunction(next){
- returnfunction(action){
- //xx
- };
- };
- };
- }
中間件會包裝 dispatch，而 dispatch 就是把 action 傳給 store 的，所以中間件自然可以拿到 action、拿到 store，還有被包裝的 dispatch，也就是 next。
比如 redux-thunk 中間件的實現(xiàn)：
- functioncreateThunkMiddleware(extraArgument){
- return({dispatch,getState})=>next=>action=>{
- if(typeofaction==='function'){
- returnaction(dispatch,getState,extraArgument);
- }
- returnnext(action);
- };
- }
- constthunk=createThunkMiddleware();
它判斷了如果 action 是一個函數(shù)，就執(zhí)行該函數(shù)，并且把 store.dispath 和 store.getState 傳進去，否則傳給內(nèi)層的 dispatch。
通過 redux-thunk 中間件，我們可以把異步過程通過函數(shù)的形式放在 dispatch 的參數(shù)里：
- constlogin=(userName)=>(dispatch)=>{
- dispatch({type:'loginStart'})
- request.post('/api/login',{data:userName},()=>{
- dispatch({type:'loginSuccess',payload:userName})
- })
- }
- store.dispatch(login('guang'))
但是這樣解決了組件里的異步過程不好復用、多個異步過程之間不好做并行、串行等控制的問題了么?
沒有，這段邏輯依然是在組件里寫，只不過移到了 dispatch 里，也沒有提供多個異步過程的管理機制。
解決這個問題，需要用 redux-saga 或 redux-observable 中間件。
redux-saga
redux-saga 并沒有改變 action，它會把 action 透傳給 store，只是多加了一條異步過程的處理。
redux-saga 中間件是這樣啟用的：
- import{createStore,applyMiddleware}from'redux'
- importcreateSagaMiddlewarefrom'redux-saga'
- importrootReducerfrom'./reducer'
- importrootSagafrom'./sagas'
- constsagaMiddleware=createSagaMiddleware()
- conststore=createStore(rootReducer,{},applyMiddleware(sagaMiddleware))
- sagaMiddleware.run(rootSaga)
要調(diào)用 run 把 saga 的 watcher saga 跑起來：
watcher saga 里面監(jiān)聽了一些 action，然后調(diào)用 worker saga 來處理：
- import{all,takeLatest}from'redux-saga/effects'
- function*rootSaga(){
- yieldall([
- takeLatest('login',login),
- takeLatest('logout',logout)
- ])
- }
- exportdefaultrootSaga
redux-saga 會先把 action 透傳給 store，然后判斷下該 action 是否是被 taker 監(jiān)聽的：
- functionsagaMiddleware({getState,dispatch}){
- returnfunction(next){
- returnfunction(action){
- constresult=next(action);//把action透傳給store
- channel.put(action);//觸發(fā)saga的action監(jiān)聽流程
- returnresult;
- }
- }
- }
當發(fā)現(xiàn)該 action 是被監(jiān)聽的，那么就執(zhí)行相應的 taker，調(diào)用 worker saga 來處理：
- function*login(action){
- try{
- constloginInfo=yieldcall(loginService,action.account)
- yieldput({type:'loginSuccess',loginInfo})
- }catch(error){
- yieldput({type:'loginError',error})
- }
- }
- function*logout(){
- yieldput({type:'logoutSuccess'})
- }
比如 login 和 logout 會有不同的 worker saga。
login 會請求 login 接口，然后觸發(fā) loginSuccess 或者 loginError 的 action。
logout 會觸發(fā) logoutSuccess 的 action。
redux saga 的異步過程管理就是這樣的：先把 action 透傳給 store，然后判斷 action 是否是被 taker 監(jiān)聽的，如果是，則調(diào)用對應的 worker saga 進行處理。
redux saga 在 redux 的 action 流程之外，加了一條監(jiān)聽 action 的異步處理的流程。
其實整個流程還是比較容易理解的。理解成本高一點的就是 generator 的寫法了：
比如下面這段代碼:
- function*xxxSaga(){
- while(true){
- yieldtake('xxx_action');
- //...
- }
- }
它就是對每一個監(jiān)聽到的 xxx_action 做同樣的處理的意思，相當于 takeEvery：
- function*xxxSaga(){
- yieldtakeEvery('xxx_action');
- //...
- }
但是因為有一個 while(true)，很多同學就不理解了，這不是死循環(huán)了么?
不是的。generator 執(zhí)行后返回的是一個 iterator，需要另外一個程序調(diào)用 next 方法才會繼續(xù)執(zhí)行。所以怎么執(zhí)行、是否繼續(xù)執(zhí)行都是由另一個程序控制的。
在 redux-saga 里面，控制 worker saga 執(zhí)行的程序叫做 task。worker saga 只是告訴了 task 應該做什么處理，通過 call、fork、put 這些命令(這些命令叫做 effect)。
然后 task 會調(diào)用不同的實現(xiàn)函數(shù)來執(zhí)行該 worker saga。
為什么要這樣設計呢?直接執(zhí)行不就行了，為啥要拆成 worker saga 和 task 兩部分，這樣理解成本不就高了么?
確實，設計成 generator 的形式會增加理解成本，但是換來的是可測試性。因為各種副作用，比如網(wǎng)絡請求、dispatch action 到 store 等等，都變成了 call、put 等 effect，由 task 部分控制執(zhí)行。那么具體怎么執(zhí)行的就可以隨意的切換了，這樣測試的時候只需要模擬傳入對應的數(shù)據(jù)，就可以測試 worker saga 了。
redux saga 設計成 generator 的形式是一種學習成本和可測試性的權衡。
還記得 redux-thunk 有啥問題么?多個異步過程之間的并行、串行的復雜關系沒法處理。那 redux-saga 是怎么解決的呢?
redux-saga 提供了 all、race、takeEvery、takeLatest 等 effect 來指定多個異步過程的關系：
比如 takeEvery 會對多個 action 的每一個做同樣的處理，takeLatest 會對多個 action 的最后一個做處理，race 會只返回最快的那個異步過程的結果，等等。
這些控制多個異步過程之間關系的 effect 正是 redux-thunk 所沒有的，也是復雜異步過程的管理必不可少的部分。
所以 redux-saga 可以做復雜異步過程的管理，而且具有很好的可測試性。
其實異步過程的管理，最出名的是 rxjs，而 redux-observable 就是基于 rxjs 實現(xiàn)的，它也是一種復雜異步過程管理的方案。
redux-observable
redux-observable 用起來和 redux-saga 特別像，比如啟用插件的部分：
- constepicMiddleware=createEpicMiddleware();
- conststore=createStore(
- rootReducer,
- applyMiddleware(epicMiddleware)
- );
- epicMiddleware.run(rootEpic);
和 redux saga 的啟動流程是一樣的，只是不叫 saga 而叫 epic。
但是對異步過程的處理，redux saga 是自己提供了一些 effect，而 redux-observable 是利用了 rxjs 的 operator：
- import{ajax}from'rxjs/ajax';
- constfetchUserEpic=(action$,state$)=>action$.pipe(
- ofType('FETCH_USER'),
- mergeMap(({payload})=>ajax.getJSON(`/api/users/${payload}`).pipe(
- map(response=>({
- type:'FETCH_USER_FULFILLED',
- payload:response
- }))
- )
- );
通過 ofType 來指定監(jiān)聽的 action，處理結束返回 action 傳遞給 store。
相比 redux-saga 來說，redux-observable 支持的異步過程的處理更豐富，直接對接了 operator 的生態(tài)，是開放的，而 redux-saga 則只是提供了內(nèi)置的幾個 effect 來處理。
所以做特別復雜的異步流程處理的時候，redux-observable 能夠利用 rxjs 的操作符的優(yōu)勢會更明顯。
但是 redux-saga 的優(yōu)點還有基于 generator 的良好的可測試性，而且大多數(shù)場景下，redux-saga 提供的異步過程的處理能力就足夠了，所以相對來說，redux-saga 用的更多一些。
總結
前端框架實現(xiàn)了數(shù)據(jù)到視圖的綁定，我們只需要關心數(shù)據(jù)流就可以了。
相比 context 的混亂的數(shù)據(jù)流，redux 的 view -> action -> store -> view 的單向數(shù)據(jù)流更清晰且容易管理。
前端代碼中有很多異步過程，這些異步過程之間可能有串行、并行甚至更復雜的關系，放在組件里并不好管理，可以放在 redux 的中間件里。
redux 的中間件就是對 dispatch 的層層包裝，比如 redux-thunk 就是判斷了下 action 是 function 就執(zhí)行下，否則就是繼續(xù) dispatch。
redux-thunk 并沒有提供多個異步過程管理的機制，復雜異步過程的管理還是得用 redux-saga 或者 redux-observable。
redux-saga 透傳了 action 到 store，并且監(jiān)聽 action 執(zhí)行相應的異步過程。異步過程的描述使用 generator 的形式，好處是可測試性。比如通過 take、takeEvery、takeLatest 來監(jiān)聽 action，然后執(zhí)行 worker saga。worker saga 可以用 put、call、fork 等 effect 來描述不同的副作用，由 task 負責執(zhí)行。
redux-observable 同樣監(jiān)聽了 action 執(zhí)行相應的異步過程，但是是基于 rxjs 的 operator，相比 saga 來說，異步過程的管理功能更強大。
不管是 redux-saga 通過 generator 來組織異步過程，通過內(nèi)置 effect 來處理多個異步過程之間的關系，還是 redux-observable 通過 rxjs 的 operator 來組織異步過程和多個異步過程之間的關系。它們都解決了復雜異步過程的處理的問題，可以根據(jù)場景的復雜度靈活選用。
原文鏈接：https://mp.weixin.qq.com/s/qBDJSoXNOVtCatOomXLrIg
