建站
咨詢
售后
建站咨詢
新聞中心
本文轉(zhuǎn)載自微信公眾號「神光的編程秘籍 」，作者神說要有光zxg。轉(zhuǎn)載本文請聯(lián)系神光的編程秘籍公眾號。
創(chuàng)新互聯(lián)建站專注于袁州網(wǎng)站建設(shè)服務(wù)及定制，我們擁有豐富的企業(yè)做網(wǎng)站經(jīng)驗。 熱誠為您提供袁州營銷型網(wǎng)站建設(shè)，袁州網(wǎng)站制作、袁州網(wǎng)頁設(shè)計、袁州網(wǎng)站官網(wǎng)定制、重慶小程序開發(fā)服務(wù)，打造袁州網(wǎng)絡(luò)公司原創(chuàng)品牌,更為您提供袁州網(wǎng)站排名全網(wǎng)營銷落地服務(wù)。
前端框架的數(shù)據(jù)流
前端框架實現(xiàn)了數(shù)據(jù)驅(qū)動視圖變化的功能，我們用 template 或者 jsx 描述好了數(shù)據(jù)和視圖的綁定關(guān)系，然后就只需要關(guān)心數(shù)據(jù)的管理了。
數(shù)據(jù)在組件和組件之間、組件和全局 store 之間傳遞，叫做前端框架的數(shù)據(jù)流。
一般來說，除了某部分狀態(tài)數(shù)據(jù)是只有某個組件關(guān)心的，我們會把狀態(tài)數(shù)據(jù)放在組件內(nèi)以外，業(yè)務(wù)數(shù)據(jù)、多個組件關(guān)心的狀態(tài)數(shù)據(jù)都會放在 store 里面。組件從 store 中取數(shù)據(jù)，當(dāng)交互的時候去通知 store 改變對應(yīng)的數(shù)據(jù)。
這個 store 不一定是 redux、mobox 這些第三方庫，其實 react 內(nèi)置的 context 也可以作為 store。但是 context 做為 store 有一個問題，任何組件都能從 context 中取出數(shù)據(jù)來修改，那么當(dāng)排查問題的時候就特別困難，因為并不知道是哪個組件把數(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ù)流動是單向的，清晰的，很容易管理。
這就像為什么我們在公司里想要什么權(quán)限都要走審批流，而不是直接找某人，一樣的道理。集中管理流程比較清晰，而且還可以追溯。
異步過程的管理
很多情況下改變 store 數(shù)據(jù)都是一個異步的過程，比如等待網(wǎng)絡(luò)請求返回數(shù)據(jù)、定時改變數(shù)據(jù)、等待某個事件來改變數(shù)據(jù)等，那這些異步過程的代碼放在哪里呢?
組件?
放在組件里是可以，但是異步過程怎么跨組件復(fù)用?多個異步過程之間怎么做串行、并行等控制?
所以當(dāng)異步過程比較多，而且異步過程與異步過程之間也不獨立，有串行、并行、甚至更復(fù)雜的關(guān)系的時候，直接把異步邏輯放組件內(nèi)不行。
不放組件內(nèi)，那放哪呢?
redux 提供的中間件機制是不是可以用來放這些異步過程呢?
redux 中間件
先看下什么是 redux 中間件：
redux 的流程很簡單，就是 dispatch 一個 action 到 store， reducer 來處理 action。那么如果想在到達 store 之前多做一些處理呢?在哪里加?
改造 dispatch!中間件的原理就是層層包裝 dispatch。
下面是 applyMiddleware 的源碼，可以看到 applyMiddleware 就是對 store.dispatch 做了層層包裝，最后返回修改了 dispatch 之后的 store。
- function applyMiddleware(middlewares) {
- let dispatch = store.dispatch
- middlewares.forEach(middleware =>
- dispatch = middleware(store)(dispatch)
- )
- return { ...store, dispatch}
- }
所以說中間件最終返回的函數(shù)就是處理 action 的 dispatch：
- function middlewareXxx(store) {
- return function (next) {
- return function (action) {
- // xx
- };
- };
- };
- }
中間件會包裝 dispatch，而 dispatch 就是把 action 傳給 store 的，所以中間件自然可以拿到 action、拿到 store，還有被包裝的 dispatch，也就是 next。
比如 redux-thunk 中間件的實現(xiàn)：
- function createThunkMiddleware(extraArgument) {
- return ({ dispatch, getState }) => next => action => {
- if (typeof action === 'function') {
- return action(dispatch, getState, extraArgument);
- }
- return next(action);
- };
- }
- const thunk = createThunkMiddleware();
它判斷了如果 action 是一個函數(shù)，就執(zhí)行該函數(shù)，并且把 store.dispath 和 store.getState 傳進去，否則傳給內(nèi)層的 dispatch。
通過 redux-thunk 中間件，我們可以把異步過程通過函數(shù)的形式放在 dispatch 的參數(shù)里：
- const login = (userName) => (dispatch) => {
- dispatch({ type: 'loginStart' })
- request.post('/api/login', { data: userName }, () => {
- dispatch({ type: 'loginSuccess', payload: userName })
- })
- }
- store.dispatch(login('guang'))
但是這樣解決了組件里的異步過程不好復(fù)用、多個異步過程之間不好做并行、串行等控制的問題了么?
沒有，這段邏輯依然是在組件里寫，只不過移到了 dispatch 里，也沒有提供多個異步過程的管理機制。
解決這個問題，需要用 redux-saga 或 redux-observable 中間件。
redux-saga
redux-saga 并沒有改變 action，它會把 action 透傳給 store，只是多加了一條異步過程的處理。
redux-saga 中間件是這樣啟用的：
- import { createStore, applyMiddleware } from 'redux'
- import createSagaMiddleware from 'redux-saga'
- import rootReducer from './reducer'
- import rootSaga from './sagas'
- const sagaMiddleware = createSagaMiddleware()
- const store = 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() {
- yield all([
- takeLatest('login', login),
- takeLatest('logout', logout)
- ])
- }
- export default rootSaga
redux-saga 會先把 action 透傳給 store，然后判斷下該 action 是否是被 taker 監(jiān)聽的：
- function sagaMiddleware({ getState, dispatch }) {
- return function (next) {
- return function (action) {
- const result = next(action);// 把 action 透傳給 store
- channel.put(action); //觸發(fā) saga 的 action 監(jiān)聽流程
- return result;
- }
- }
- }
當(dāng)發(fā)現(xiàn)該 action 是被監(jiān)聽的，那么就執(zhí)行相應(yīng)的 taker，調(diào)用 worker saga 來處理：
- function* login(action) {
- try {
- const loginInfo = yield call(loginService, action.account)
- yield put({ type: 'loginSuccess', loginInfo })
- } catch (error) {
- yield put({ type: 'loginError', error })
- }
- }
- function* logout() {
- yield put({ 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)用對應(yīng)的 worker saga 進行處理。
redux saga 在 redux 的 action 流程之外，加了一條監(jiān)聽 action 的異步處理的流程。
其實整個流程還是比較容易理解的。理解成本高一點的就是 generator 的寫法了：
比如下面這段代碼:
- function* xxxSaga() {
- while(true) {
- yield take('xxx_action');
- //...
- }
- }
它就是對每一個監(jiān)聽到的 xxx_action 做同樣的處理的意思，相當(dāng)于 takeEvery：
- function* xxxSaga() {
- yield takeEvery('xxx_action');
- //...
- }
但是因為有一個 while(true)，很多同學(xué)就不理解了，這不是死循環(huán)了么?
不是的。generator 執(zhí)行后返回的是一個 iterator，需要另外一個程序調(diào)用 next 方法才會繼續(xù)執(zhí)行。所以怎么執(zhí)行、是否繼續(xù)執(zhí)行都是由另一個程序控制的。
在 redux-saga 里面，控制 worker saga 執(zhí)行的程序叫做 task。worker saga 只是告訴了 task 應(yīng)該做什么處理，通過 call、fork、put 這些命令(這些命令叫做 effect)。
然后 task 會調(diào)用不同的實現(xiàn)函數(shù)來執(zhí)行該 worker saga。
為什么要這樣設(shè)計呢?直接執(zhí)行不就行了，為啥要拆成 worker saga 和 task 兩部分，這樣理解成本不就高了么?
確實，設(shè)計成 generator 的形式會增加理解成本，但是換來的是可測試性。因為各種副作用，比如網(wǎng)絡(luò)請求、dispatch action 到 store 等等，都變成了 call、put 等 effect，由 task 部分控制執(zhí)行。那么具體怎么執(zhí)行的就可以隨意的切換了，這樣測試的時候只需要模擬傳入對應(yīng)的數(shù)據(jù)，就可以測試 worker saga 了。
redux saga 設(shè)計成 generator 的形式是一種學(xué)習(xí)成本和可測試性的權(quán)衡。
還記得 redux-thunk 有啥問題么?多個異步過程之間的并行、串行的復(fù)雜關(guān)系沒法處理。那 redux-saga 是怎么解決的呢?
redux-saga 提供了 all、race、takeEvery、takeLatest 等 effect 來指定多個異步過程的關(guān)系：
比如 takeEvery 會對多個 action 的每一個做同樣的處理，takeLatest 會對多個 action 的最后一個做處理，race 會只返回最快的那個異步過程的結(jié)果，等等。
這些控制多個異步過程之間關(guān)系的 effect 正是 redux-thunk 所沒有的，也是復(fù)雜異步過程的管理必不可少的部分。
所以 redux-saga 可以做復(fù)雜異步過程的管理，而且具有很好的可測試性。
其實異步過程的管理，最出名的是 rxjs，而 redux-observable 就是基于 rxjs 實現(xiàn)的，它也是一種復(fù)雜異步過程管理的方案。
redux-observable
redux-observable 用起來和 redux-saga 特別像，比如啟用插件的部分：
- const epicMiddleware = createEpicMiddleware();
- const store = createStore(
- rootReducer,
- applyMiddleware(epicMiddleware)
- );
- epicMiddleware.run(rootEpic);
和 redux saga 的啟動流程是一樣的，只是不叫 saga 而叫 epic。
但是對異步過程的處理，redux saga 是自己提供了一些 effect，而 redux-observable 是利用了 rxjs 的 operator：
- import { ajax } from 'rxjs/ajax';
- const fetchUserEpic = (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，處理結(jié)束返回 action 傳遞給 store。
相比 redux-saga 來說，redux-observable 支持的異步過程的處理更豐富，直接對接了 operator 的生態(tài)，是開放的，而 redux-saga 則只是提供了內(nèi)置的幾個 effect 來處理。
所以做特別復(fù)雜的異步流程處理的時候，redux-observable 能夠利用 rxjs 的操作符的優(yōu)勢會更明顯。
但是 redux-saga 的優(yōu)點還有基于 generator 的良好的可測試性，而且大多數(shù)場景下，redux-saga 提供的異步過程的處理能力就足夠了，所以相對來說，redux-saga 用的更多一些。
總結(jié)
前端框架實現(xiàn)了數(shù)據(jù)到視圖的綁定，我們只需要關(guān)心數(shù)據(jù)流就可以了。
相比 context 的混亂的數(shù)據(jù)流，redux 的 view -> action -> store -> view 的單向數(shù)據(jù)流更清晰且容易管理。
前端代碼中有很多異步過程，這些異步過程之間可能有串行、并行甚至更復(fù)雜的關(guān)系，放在組件里并不好管理，可以放在 redux 的中間件里。
redux 的中間件就是對 dispatch 的層層包裝，比如 redux-thunk 就是判斷了下 action 是 function 就執(zhí)行下，否則就是繼續(xù) dispatch。
redux-thunk 并沒有提供多個異步過程管理的機制，復(fù)雜異步過程的管理還是得用 redux-saga 或者 redux-observable。
redux-saga 透傳了 action 到 store，并且監(jiān)聽 action 執(zhí)行相應(yīng)的異步過程。異步過程的描述使用 generator 的形式，好處是可測試性。比如通過 take、takeEvery、takeLatest 來監(jiān)聽 action，然后執(zhí)行 worker saga。worker saga 可以用 put、call、fork 等 effect 來描述不同的副作用，由 task 負責(zé)執(zhí)行。
redux-observable 同樣監(jiān)聽了 action 執(zhí)行相應(yīng)的異步過程，但是是基于 rxjs 的 operator，相比 saga 來說，異步過程的管理功能更強大。
不管是 redux-saga 通過 generator 來組織異步過程，通過內(nèi)置 effect 來處理多個異步過程之間的關(guān)系，還是 redux-observable 通過 rxjs 的 operator 來組織異步過程和多個異步過程之間的關(guān)系。它們都解決了復(fù)雜異步過程的處理的問題，可以根據(jù)場景的復(fù)雜度靈活選用。
文章標題：深入理解Redux數(shù)據(jù)流和異步過程管理
標題路徑：http://www.dlmjj.cn/article/cdigjji.html
