韩国一级片免费,精品日韩欧美国产一区二区 ,最近中文字幕完先锋资源

深入理解 Redux 數據流和異步過程管理

前端框架的數據流

前端框架實現了數據驅動視圖變化的功能，我們用 template 或者 jsx 描述好了數據和視圖的綁定關系，然后就只需要關心數據的管理了。

數據在組件和組件之間、組件和全局 store 之間傳遞，叫做前端框架的數據流。

一般來說，除了某部分狀態數據是只有某個組件關心的，我們會把狀態數據放在組件內以外，業務數據、多個組件關心的狀態數據都會放在 store 里面。組件從 store 中取數據，當交互的時候去通知 store 改變對應的數據。

這個 store 不一定是 redux、mobox 這些第三方庫，其實 react 內置的 context 也可以作為 store。但是 context 做為 store 有一個問題，任何組件都能從 context 中取出數據來修改，那么當排查問題的時候就特別困難，因為并不知道是哪個組件把數據改壞的，也就是數據流不清晰。

正是因為這個原因，我們幾乎見不到用 context 作為 store，基本都是搭配一個 redux。

所以為什么 redux 好呢?第一個原因就是數據流清晰，改變數據有統一的入口。

深入理解 Redux 數據流和異步過程管理

組件里都是通過 dispatch 一個 action 來觸發 store 的修改，而且修改的邏輯都是在 reducer 里面，組件再監聽 store 的數據變化，從中取出最新的數據。

這樣數據流動是單向的，清晰的，很容易管理。

這就像為什么我們在公司里想要什么權限都要走審批流，而不是直接找某人，一樣的道理。集中管理流程比較清晰，而且還可以追溯。

異步過程的管理

很多情況下改變 store 數據都是一個異步的過程，比如等待網絡請求返回數據、定時改變數據、等待某個事件來改變數據等，那這些異步過程的代碼放在哪里呢?

組件?

放在組件里是可以，但是異步過程怎么跨組件復用?多個異步過程之間怎么做串行、并行等控制?

所以當異步過程比較多，而且異步過程與異步過程之間也不獨立，有串行、并行、甚至更復雜的關系的時候，直接把異步邏輯放組件內不行。

不放組件內，那放哪呢?

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}
}

所以說中間件最終返回的函數就是處理 action 的 dispatch：

functionmiddlewareXxx(store){
returnfunction(next){
returnfunction(action){
//xx
};
};
};
}

中間件會包裝 dispatch，而 dispatch 就是把 action 傳給 store 的，所以中間件自然可以拿到 action、拿到 store，還有被包裝的 dispatch，也就是 next。

比如 redux-thunk 中間件的實現：

functioncreateThunkMiddleware(extraArgument){
return({dispatch,getState})=>next=>action=>{
if(typeofaction==='function'){
returnaction(dispatch,getState,extraArgument);
}
returnnext(action);
};
}
constthunk=createThunkMiddleware();

它判斷了如果 action 是一個函數，就執行該函數，并且把 store.dispath 和 store.getState 傳進去，否則傳給內層的 dispatch。

通過 redux-thunk 中間件，我們可以把異步過程通過函數的形式放在 dispatch 的參數里：

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 數據流和異步過程管理

redux-saga 中間件是這樣啟用的：

import{createStore,applyMiddleware}from'redux'
importcreateSagaMiddlewarefrom'redux-saga'
importrootReducerfrom'./reducer'
importrootSagafrom'./sagas'
constsagaMiddleware=createSagaMiddleware()
conststore=createStore(rootReducer,{},applyMiddleware(sagaMiddleware))
sagaMiddleware.run(rootSaga)

要調用 run 把 saga 的 watcher saga 跑起來：

watcher saga 里面監聽了一些 action，然后調用 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 監聽的：

functionsagaMiddleware({getState,dispatch}){
returnfunction(next){
returnfunction(action){
constresult=next(action);//把action透傳給store
channel.put(action);//觸發saga的action監聽流程
returnresult;
}
}
}

當發現該 action 是被監聽的，那么就執行相應的 taker，調用 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。

logout 會觸發 logoutSuccess 的 action。

redux saga 的異步過程管理就是這樣的：先把 action 透傳給 store，然后判斷 action 是否是被 taker 監聽的，如果是，則調用對應的 worker saga 進行處理。

redux saga 在 redux 的 action 流程之外，加了一條監聽 action 的異步處理的流程。

其實整個流程還是比較容易理解的。理解成本高一點的就是 generator 的寫法了：

比如下面這段代碼:

function*xxxSaga(){
while(true){
yieldtake('xxx_action');
//...
}
}

它就是對每一個監聽到的 xxx_action 做同樣的處理的意思，相當于 takeEvery：

function*xxxSaga(){
yieldtakeEvery('xxx_action');
//...
}

但是因為有一個 while(true)，很多同學就不理解了，這不是死循環了么?

不是的。generator 執行后返回的是一個 iterator，需要另外一個程序調用 next 方法才會繼續執行。所以怎么執行、是否繼續執行都是由另一個程序控制的。

在 redux-saga 里面，控制 worker saga 執行的程序叫做 task。worker saga 只是告訴了 task 應該做什么處理，通過 call、fork、put 這些命令(這些命令叫做 effect)。

然后 task 會調用不同的實現函數來執行該 worker saga。

為什么要這樣設計呢?直接執行不就行了，為啥要拆成 worker saga 和 task 兩部分，這樣理解成本不就高了么?

確實，設計成 generator 的形式會增加理解成本，但是換來的是可測試性。因為各種副作用，比如網絡請求、dispatch action 到 store 等等，都變成了 call、put 等 effect，由 task 部分控制執行。那么具體怎么執行的就可以隨意的切換了，這樣測試的時候只需要模擬傳入對應的數據，就可以測試 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 實現的，它也是一種復雜異步過程管理的方案。

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 來指定監聽的 action，處理結束返回 action 傳遞給 store。

相比 redux-saga 來說，redux-observable 支持的異步過程的處理更豐富，直接對接了 operator 的生態，是開放的，而 redux-saga 則只是提供了內置的幾個 effect 來處理。

所以做特別復雜的異步流程處理的時候，redux-observable 能夠利用 rxjs 的操作符的優勢會更明顯。

但是 redux-saga 的優點還有基于 generator 的良好的可測試性，而且大多數場景下，redux-saga 提供的異步過程的處理能力就足夠了，所以相對來說，redux-saga 用的更多一些。

總結

前端框架實現了數據到視圖的綁定，我們只需要關心數據流就可以了。

相比 context 的混亂的數據流，redux 的 view -> action -> store -> view 的單向數據流更清晰且容易管理。

前端代碼中有很多異步過程，這些異步過程之間可能有串行、并行甚至更復雜的關系，放在組件里并不好管理，可以放在 redux 的中間件里。

redux 的中間件就是對 dispatch 的層層包裝，比如 redux-thunk 就是判斷了下 action 是 function 就執行下，否則就是繼續 dispatch。

redux-thunk 并沒有提供多個異步過程管理的機制，復雜異步過程的管理還是得用 redux-saga 或者 redux-observable。

redux-saga 透傳了 action 到 store，并且監聽 action 執行相應的異步過程。異步過程的描述使用 generator 的形式，好處是可測試性。比如通過 take、takeEvery、takeLatest 來監聽 action，然后執行 worker saga。worker saga 可以用 put、call、fork 等 effect 來描述不同的副作用，由 task 負責執行。

redux-observable 同樣監聽了 action 執行相應的異步過程，但是是基于 rxjs 的 operator，相比 saga 來說，異步過程的管理功能更強大。

不管是 redux-saga 通過 generator 來組織異步過程，通過內置 effect 來處理多個異步過程之間的關系，還是 redux-observable 通過 rxjs 的 operator 來組織異步過程和多個異步過程之間的關系。它們都解決了復雜異步過程的處理的問題，可以根據場景的復雜度靈活選用。

原文鏈接：https://mp.weixin.qq.com/s/qBDJSoXNOVtCatOomXLrIg