本文由 簡悅 SimpRead 轉碼， 原文地址 https://github.com/sorrycc/blog/issues/1

更新：我們基于此最佳實踐做了一個封裝方案：dva，可以簡化使用 redux 和 redux-saga 時很多繁雜的操作。

前端變化雖快，但其實一直都圍繞這幾個概念在轉：

• URL - 訪問什么頁面
• Data - 顯示什么信息
• View - 頁面長成什么樣
• Action - 對頁面做了什么操作
• API Server - Data 數據的來源

在 Redux 的生態圈內，每個環節有多種方案，比如 Data 可以是 immutable 或者 plain object，在你選了 immutable 之后，用 immutable.js 還是 seamless-immutable，以及是否用 redux-immutable 來輔助數據修改，都需要選擇。

本文總結目前 react + redux 的最佳實踐，解釋原因，并提供可選方案。

心急的朋友可以直接看代碼：https://github.com/sorrycc/github-stars

一、URL > Data

需求

routing

選擇

react-router + react-router-redux: 前者是業界標準，后者可以同步 route 信息到 state，這樣你可以在 view 根據 route 信息調整展現，以及通過 action 來修改 route 。

可選

無

二、Data

需求

為 redux 提供數據源，修改容易。

方案

plain object: 配合 combineReducer 已經可以滿足需求。

同時在組織 Store 的時候，層次不要太深，盡量保持在 2 - 3 層。如果層次深，可以考慮用 updeep 來輔助修改數據。

可選

immutable.js: 通過自定義的 api 來操作數據，需要額外的學習成本。不熟悉 immutable.js 的可以先嘗試用 seamless-immutable，JavaScript 原生接口，無學習門檻。

另外，不推薦用 redux-immutable 以及 redux-immutablejs，一是沒啥必要，具體看他們的實現就知道了，都比較簡單；更重要的是他們都改寫了 combineReducer，會帶來潛在的一些兼容問題。

三、Data > View

需求

數據的過濾和篩選。

方案

reselect: store 的 select 方案，用于提取數據的篩選邏輯，讓 Component 保持簡單。選 reselct 看重的是 可組合特性 和 緩存機制 。

可選

無

四、View 之 CSS 方案

需求

合理的 CSS 方案，考慮團隊協作。

方案

css-modules: 配合 webpack 的 css-loader 進行打包，會為所有的 class name 和 animation name 加 local scope，避免潛在沖突。

直接看代碼：

Header.jsx

import style from './Header.less';
export default () => <div className={style.normal} />;

Header.less

.normal { color: red; }

編譯后，文件中的 style.normal 和 .normal 在會被重命名為類似 Header__normal___VI1de 。

可選

bem, rscss ，這兩個都是基于約定的方案。但基于約定會帶來額外的學習成本和不遍，比如 rscss 要求所有的 Component 都是兩個詞的連接，比如 Header 就必須換成類似 HeaderBox 這樣。

radium，inline css 方案，沒研究。

五、Action <> Store，業務邏輯處理

需求

統一處理業務邏輯，尤其是異步的處理。

方案

redux-saga: 用于管理 action，處理異步邏輯。可測試、可 mock、聲明式的指令。

可選

redux-loop: 適用于相對簡單點的場景，可以組合異步和同步的 action 。但他有個問題是改寫了 combineReducer，會導致一些意想不到的兼容問題，比如我在特定場景下用不了 redux-devtool 。

redux-thunk, redux-promise 等: 相對原始的異步方案，適用于更簡單的場景。在 action 需要組合、取消等操作時，會不好處理。

saga 入門

在 saga 之前，你可能會在 action creator 里處理業務邏輯，雖然能跑通，但是難以測試。比如：

// action creator with thunking
function createRequest () {
  return (dispatch, getState) => {
    dispatch({ type: 'REQUEST_STUFF' });
    someApiCall(function(response) {
      // some processing
      dispatch({ type: 'RECEIVE_STUFF' });
    });
  };
}

然后組件里可能這樣：

function onHandlePress () {
  this.props.dispatch({ type: 'SHOW_WAITING_MODAL' });
  this.props.dispatch(createRequest());
}

這樣通過 redux state 和 reducer 把所有的事情串聯到起來。

但問題是：

Code is everywhere.

通過 saga，你只需要觸發一個 action 。

function onHandlePress () {
  // createRequest 觸發 action `BEGIN_REQUEST`
  this.props.dispatch(createRequest());
}

然后所有后續的操作都通過 saga 來管理。

function *hello() {
  // 等待 action `BEGIN_REQUEST`
  yield take('BEGIN_REQUEST');
  // dispatch action `SHOW_WAITING_MODAL`
  yield put({ type: 'SHOW_WAITING_MODAL' });
  // 發布異步請求
  const response = yield call(myApiFunctionThatWrapsFetch);
  // dispatch action `PRELOAD_IMAGES`, 附上 response 信息
  yield put({ type: 'PRELOAD_IMAGES', response.images });
  // dispatch action `HIDE_WAITING_MODAL`
  yield put({ type: 'HIDE_WAITING_MODAL' });
}

可以看出，調整之后的代碼有幾個優點：

• 所有業務代碼都存于 saga 中，不再散落在各處
• 全同步執行，就算邏輯再復雜，看起來也不會亂

六、Data <-> API Server

需求

異步請求。

方案

isomorphic-fetch: 便于在同構應用中使用，另外同時要寫 node 和 web 的同學可以用一個庫，學一套 api 。

然后通過 async + await 組織代碼。

示例代碼：

import fetch from 'isomorphic-fetch';
export async function fetchUser(uid) {
  return await fetch(`/users/${uid}`).then(res => res.json());
};

可選

reqwest

最終

（完）