標籤:

redux-saga 實踐總結

有關 redux-saga 的文章,網路上早已是汗牛充棟。因此,本篇主要談一談自己的理解,以及實踐中的經驗總結。

眾所周知,redux 大部分的想法,都來自於elm。在 elm 和 redux 中,整個應用就是一個純函數。elm 通過在 reducer 中返回一些聲明副作用的 task 來處理非同步問題,而 redux 借鑒 koa 的插件機制,用中間件改造 dispatch ,從而誕生了一批通過構造滿足特殊 pattern 條件的 action 來解決副作用的問題。

而 redux-saga 獨闢蹊徑,監聽 action 來執行有副作用的 task,以保持 action 的簡潔性。並且引入了 sagas 的機制和 generator 的特性,讓redux-saga 非常方便地處理複雜非同步問題。

有意思的是,redux 借鑒了 elm,但在處理非同步問題(副作用問題在前端一般為非同步問題)上,借鑒了 koa 中間件的形式,而 redux-saga 卻又去從 elm 取經,借鑒了獨立 task 的形式。但是說到底,redux-saga 是一個 redux 的中間件。這個故事告訴我們,有好的設計不如有強大的擴展性。

redux-saga 本身也有良好的擴展性。比如,易證得,但凡 redux 中間件,都可以用 redux-saga 來重寫。當然了,不是說用了 redux-saga,其它非同步中間件就不能用了,只是說不能保證 redux-saga 能恰好和你之前使用的中間件配合良好。

redux-saga 簡介

redux-saga 是一個 redux 中間件,它具有如下特性:

  • 集中處理 redux 副作用問題。

  • 被實現為 generator 。

  • 類 redux-thunk 中間件。

  • watch/worker(監聽->執行) 的工作形式。

讀者也可以從這裡查看官方定義。

對於剛接觸 redux-saga 的同學,可以先來一段簡單的代碼快速了解 redux-saga 諸多特性。

// 類 thunk 的 worker 「進程」nfunction* load() {n yield put({ type: BEGIN_LOAD_DATA });n n try {n const result = yield call(fetch, UrlMap.loadData);nn yield put({n type: LOAD_DATA_SUCCESS,n payload: result,n });n } catch (e) {n yield put({n type: LOAD_DATA_ERROR,n payload: e,n error: true,n });n }n}nnfunction* saga() {n // 創建一個監聽「進程」n yield fork(watch(CLICK_LOAD_BUTTON, load))n}n

Effects

Effect 是一個 javascript 對象,裡面包含描述副作用的信息,可以通過 yield 傳達給 sagaMiddleware 執行

在 redux-saga 世界裡,所有的 Effect 都必須被 yield 才會執行,所以有人寫了 eslint-plugin-redux-saga 來檢查是否每個 Effect 都被 yield。並且原則上來說,所有的 yield 後面也只能跟Effect,以保證代碼的易測性。

例如:

yield fetch(UrlMap.fetchData);n

應該用 call Effect :

yield call(fetch, UrlMap.fetchData)n

從而可以使代碼可測:

assert.deepEqual(iterator.next().value, call(fetch, UrlMap.fetchData))n

關於各個 Effect 的具體介紹,文檔已經寫得很詳細了,這裡只做簡要介紹。

1、put

作用和 redux 中的 dispatch 相同。

yield put({ type: CLICK_BTN });n

2、select

作用和 redux thunk 中的 getState 相同。

const id = yield select(state => state.id);n

3、take

等待 redux dispatch 匹配某個 pattern 的 action 。

在這個例子中,先等待一個按鈕點擊的 action ,然後執行按鈕點擊的 saga:

while (true) {n yield take(CLICK_BUTTON);n yield fork(clickButtonSaga);n}n

再舉一個利用 take 實現 logMiddleware 的例子:

while (true) {n const action = yield take(*);n const newState = yield select();n n console.log(received action:, action);n console.log(state become:, newState);n}n

這種監聽一個 action ,然後執行相應任務的方式,在 redux-saga 中非常常用,因此 redux-saga 提供了一個輔助 Effect —— takeEvery ,讓 watch/worker 的代碼更加清晰。

yield takeEvery(*, function* logger(action) {n const newState = yield select();nn console.log(received action:, action);n console.log(state become:, newState);n});n

4、阻塞調用和無阻塞調用

redux-saga 可以用 fork 和 call 來調用子 saga ,其中 fork 是無阻塞型調用,call 是阻塞型調用。

如果看過 saga 的論文,就知道 saga 是由許多子 saga (或者 subtransaction)組合起來的。fork Effect 和它的字面意思一樣,即創建一個子 saga 。

4.1、fork

下面寫一個倒數的例子,當接收到 BEGIN_COUNT 的 action,則開始倒數,而接收到 STOP_COUNT 的 action, 則停止倒數。

function* count(number) {n let currNum = number;nn while (currNum >= 0) {n console.log(currNum--);n yield delay(1000);n }n}nnfunction countSaga* () {n while (true) {n const { payload: number } = yield take(BEGIN_COUNT);n const countTaskId = yield fork(count, number);nn yield take(STOP_TASK);n yield cancel(countTaskId);n }n}n

4.2、call

有阻塞地調用 saga 或者返回 promise 的函數。

同樣寫一個例子:

const project = yield call(fetch, { url: UrlMap.fetchProject });nconst members = yield call(fetchMembers, project.id);n

另附 redux-saga 文檔:

英文文檔

中文文檔

傳統非同步中間件簡介

在介紹 redux-saga 優缺點之前,這裡先簡要介紹傳統的 redux 非同步中間件,以便和 redux-saga 做比較。對傳統非同步中間件已經充分了解的讀者,可以直接跳到 「redux-saga 優缺點分析」 進行閱讀。

1. fetch-middleware

使用redux的前端技術團隊或個人,大多數都有一套自己 fetch-middleware,一來可以封裝非同步請求的業務邏輯,避免重複代碼,二來可以寫一些公共的非同步請求邏輯,比如異常介面數據採集、介面緩存、介面處理等等。例如 redux-composable-fetch,redux-api-middleware。

在當前 redux 社區中,fetch-middleware 封裝結果一般如下:

function loadData(id) {n return {n url: /api.json,n types: [LOADING_ACTION_TYPE, SUCCESS_ACTION_TYPE, FAILURE_ACTION_TYPE],n params: {n id,n },n };n}n

值得一提的是,大多數 fetch-middleware 都會用到一個小技巧 —— 把最終處理好的 promise 返回出來,以便在 thunk-middleware 中復用,並組織不同非同步過程的先後邏輯。

function loadDetailThunk(id) {n return (dispatch) => {n // 先請求到 loadData 的結果,再請求 loadDetailn dispatch(loadData(id)).then(result => {n const { id: detailId } = result;n dispatch(loadDetail(detailId));n });n };n}n

這個技巧在 redux-saga 中也同樣有效。

function* loadDetailSaga(id) {n const result = yield put.sync(loadData(id));n const { id: detailId } = result;nn yield put.sync(loadDetail(detailId));n}n

2. redux-thunk-middleware

redux 中大量應用了 thunk 的概念,例如 getState 以延遲執行的方式可以始終獲得最新值,redux-thunk 以延遲執行的方式把副作用的責任推卸到用戶身上。

任何非同步問題都能在 thunk 中解決。

3. sequence-middleware

sequence-middleware 用於保證 action 依次執行,無論是非同步 action 還是普通 aciton ,和 fetch-middleware 配合使用非常方便。

這裡可以把每個 action 可以寫成 thunk action,在 thunk 函數內從 store 拿到參數,避免 action 之間的依賴。這樣不管業務邏輯有多複雜,都可以通過用 sequence action 輕易組織。

function loadDetailThunk() {n return function(dispatch, getState) {n const detailId = _.get(getState(), `${currPath}.detailId`);nn dispatch({n url: UrlMap.getDetail,n params: { detailId },n });n };n}nnfunction loadDetail() {n return [loadData(), loadDetailThunk()];n}n

redux-saga 優缺點分析

缺點

  • redux-saga 不強迫我們捕獲異常,這往往會造成異常發生時難以發現原因。因此,一個良好的習慣是,相信任何一個過程都有可能發生異常。如果出現異常但沒有被捕獲,redux-saga 的錯誤棧會給你一種一臉懵逼的感覺。

  • generator 的調試環境比較糟糕,babel 的 source-map 經常錯位,經常要手動加 debugger 來調試。

  • 你團隊中使用的其它非同步中間件,或許難以和 redux-saga 搭配良好。或許需要花費一些代價,用 redux-saga 來重構一部分中間件。

優點

  • 保持 action 的簡單純粹,aciton 不再像原來那樣五花八門,讓人眼花繚亂。task 的模式使代碼更加清晰。

  • redux-saga 提供了豐富的 Effects,以及 sagas 的機制(所有的 saga 都可以被中斷),在處理複雜的非同步問題上十分趁手。如果你的應用屬於寫操作密集型或者業務邏輯複雜,快讓 redux-saga 來拯救你。

  • 擴展性強。

  • 聲明式的 Effects,使代碼更易測試,查看詳情。

利用 redux-saga 寫 redux 中間件

用 redux-saga 來寫中間件,可謂事半功倍。這裡舉一個輪詢中間件的例子。

function* pollingSaga(fetchAction) {n const { defaultInterval, mockInterval } = fetchAction;nn while (true) {n try {n const result = yield put.sync(fetchAction);n const interval = mockInterval || result.interval;nn yield delay(interval * 1000);n } catch (e) {n yield delay(defaultInterval * 1000);n }n }n}nnfunction* beginPolling(pollingAction) {n const { pollingUrl, defaultInterval = 300, mockInterval, types,n params = {} } = pollingAction;nn if (!types[1]) {n console.error(pollingAction pattern error, pollingAction);n throw Error(pollingAction types[1] is null);n }nn const fetchAction = {n url: pollingUrl,n types,n params,n mockInterval,n defaultInterval,n };nn const pollingTaskId = yield fork(pollingSaga, fetchAction);n const pattern = action => action.type === types[1] && action.stopPolling;nn yield take(pattern);n yield cancel(pollingTaskId);n}nnfunction* pollingSagaMiddleware() {n yield takeEvery(action => {n const { pollingUrl, types } = action;nn return pollingUrl && types && types.length;n }, beginPolling);n};n

最後,redux-saga 在實踐的沉澱,我已經總結到 redux-saga-sugar,歡迎點贊 ~


推薦閱讀:

Redux中的reducer到底是什麼,以及它為什麼叫reducer?
如何規模化React應用
react redux 某個state變化之後 如何觸發一些操作?
感覺redux寫起來很麻煩,目前有那些其他的狀態管理方案?

TAG:React | Redux |