使用React + Redux + React-router構建可擴展的前端應用

作者：supnate 2016-10-31 11:26:13

本文最初來源于筆者在 StuQ 的一次同名課程直播，現(xiàn)在加以整理成文，希望能對更多的人有所啟發(fā)。為了固化這種實踐方式，當時還開發(fā)了一個名為 Rekit 的工具，用于確保項目能夠始終遵循這種實踐方式。現(xiàn)在工具也獲得進一步完善，大家也可以結合 Rekit 來理解文中提到的實踐方案。

現(xiàn)在是前端開發(fā)***的時代，有太多很好的框架和工具幫你更好的實現(xiàn)復雜需求;同時又是最困難的時代，因為需要掌握太多的框架和工具。如何利用好各種框架來提高前端開發(fā)質(zhì)量是大家都在探索的問題。本文就將介紹如何使用 React 及其相關技術，來進行實際前端項目的開發(fā)。因為主要介紹如何將技術用于實踐，所以希望讀者已經(jīng)對相關概念已經(jīng)有一定的了解。

[[174836]]

其實無論使用什么樣的技術，一個理想中的 Web 項目大概都需要考慮以下幾個方面：

易于開發(fā)：在功能開發(fā)時，無需關注復雜的技術架構，能夠直觀的寫功能相關的代碼。
易于擴展：增加新功能時，無需對已有架構進行調(diào)整，新功能和已有功能具有很好的隔離性，并能很好的銜接。新功能的增加并不會帶來顯著的性能問題。
易于維護：代碼直觀易讀易理解。即使是新加入的開發(fā)成員，也能夠很快的理解技術架構和代碼邏輯。
易于測試：代碼單元性好，能夠盡量使用純函數(shù)。無需或很少需要 mock 即可完成單元測試。
易于構建：代碼和靜態(tài)資源結構符合主流模式，能夠使用標準的構建工具進行構建。無需自己實現(xiàn)復雜的構建邏輯。

這些方面并不是互相獨立，而是互相依賴互相制約。當某個方面做到***，其它點就會受到影響。舉例來說，寫一個計數(shù)器功能，用jQuery一個頁面內(nèi)即可完成，但是易開發(fā)了，卻不易擴展。因此我們通常都需要根據(jù)實際項目情況在這些點之間做一個權衡，達到適合項目的***狀態(tài)。慶幸的是，現(xiàn)在的前端技術快速發(fā)展，不斷出現(xiàn)的新技術幫助我們在各個方面都獲得很大提升。

本文將要介紹的就是如何利用 React + Redux + React-router 來構建可擴展的前端應用。這里強調(diào)可擴展，因為傳統(tǒng)前端實現(xiàn)方案通常在面對復雜應用時常常力不從心，代碼結構容易混亂，性能問題難以解決。而可擴展則意味著能夠從項目的初始階段就具有了支持復雜項目的能力。首先我們看下涉及到的主要技術。

React

React 相信大家已經(jīng)非常熟悉，其組件化的思想和虛擬 DOM 的實現(xiàn)都是顛覆性的變革，從而讓前端開發(fā)可以在新的方向上不斷提升。無論是 React-hot-loader，Redux 還是 React-router，都正是因為充分利用了 React 的這些特性，才能夠提供如此強大的功能。筆者曾經(jīng)寫過《深入淺出React》的系列文章，有需要的話可以進一步閱讀。

Redux

Redux 是 JavaScript 程序狀態(tài)管理框架。盡管是一個通用型的框架，但是和 React 在一起能夠更好的工作，因為當狀態(tài)變化時，React 可以不用關心變化的細節(jié)，由虛擬 DOM 機制完成優(yōu)化過的UI更新邏輯。

Redux 也被認為整個 React 生態(tài)圈最難掌握的技術之一。其 action，reducer 和各種中間件雖然將代碼邏輯充分隔離，即常說的 separation of concerns，但在一定程度上也給開發(fā)帶來了不便。這也是上面提到的，在易維護、易擴展、易測試上得到了提升，那么易開發(fā)則受到了影響。

React-router

即使對于一個簡單的應用，路由功能也是極其重要的。正如傳統(tǒng) Web 程序用頁面來組織不同的功能模塊，由不同的 URL 來區(qū)分和導航，單頁應用使用 Router 來實現(xiàn)同樣的功能，只是在前端進行渲染而不是服務器端。React 應用的“標準”路由方案就是使用 React-router。

路由功能不僅讓用戶更容易使用(例如刷新頁面后維持 UI)，也能夠在開發(fā)時讓我們思考如何更好組織功能單元，這也是功能復雜之后的必然需求。所以即使一開始的需求很簡單，我們也應該引入 React-router 幫助我們以頁面為單元進行功能的組織。

其它需要的技術

正如前面提到的，開發(fā)前端應用需要很多周邊技術，這進一步增加了前端開發(fā)的門檻，例如：

使用 Babel 支持 ES2016 和 JSX 語法;
使用 react-redux 將 Redux 和 React 無縫結合;
使用 Webpack 進行項目打包;
使用 webpack-dll-plugin 優(yōu)化打包性能;
使用 ESLint 進行語法檢查;
使用 Mocha，Enzyme，Istanbul 進行單元測試;
使用 Less、Scss 或其它進行 CSS 預編譯。

這些工具提高了前端開發(fā)的能力和效率，但是了解并配置它們卻并非易事，而事實上這些工具和需要開發(fā)的功能并沒有直接的關系。使用工具來自動化這些配置是必然的發(fā)展方向，正如現(xiàn)在開發(fā)一個 C++ 應用，Visual Studio 會幫你完成所有的配置并搭建合適的項目結構，讓你專注于功能邏輯的開發(fā)。無論是自己實現(xiàn)，還是利用第三方，我們都應該為自己的項目創(chuàng)建這樣的工具鏈。

簡單介紹了相關技術，下面我們來看如何去構建可擴展的 Web 項目。

按功能(feature)來組織文件夾結構

無論是 Flux 還是 Redux，提供的官方示例都是以技術邏輯來組織文件夾的，例如，下面是 Redux 的 Todo 示例應用的文件夾結構：

雖然這種模式在技術上很清晰，在實際項目中卻有很大的缺點：

難以擴展。當應用功能增加，規(guī)模變大時，一個 components 文件夾下可能會有幾十上百個文件，組件間的關系極不直觀。
難以開發(fā)。在開發(fā)某個功能時，通常需要同時開發(fā)組件，action，reducer 和樣式。把它們分布在不同文件夾下嚴重影響開發(fā)效率。尤其是項目復雜之后，不同文件的切換會消耗大量時間。

因此，我們使用按功能來組織文件夾的方式，即功能相關的代碼放到一個文件夾。例如，對于一個簡單論壇程序，可能包含 user，topic，comment 這么幾個核心功能。

每個功能文件夾下包含自己的頁面，組件，樣式，action 和 reducer。

這種文件夾結構在功能上而非技術上對代碼邏輯進行區(qū)分，使得應用具有更好的擴展性，當增加新的功能時，只需增加一個新的文件夾即可;刪除功能時同理。

使用頁面(Page)的概念

前面提到了路由是當今前端應用的不可缺少的部分之一，那么對應到組件級別，就是頁面組件。因此我們在開發(fā)的過程中，需要明確定義頁面的概念：

一個頁面擁有自己的 URL 地址。頁面的展現(xiàn)和隱藏完全由 React-router 進行控制。當創(chuàng)建一個頁面時，通常意味著在路由配置里增加一條新的規(guī)則。這和傳統(tǒng) Web 應用非常類似。
一個頁面對應 Redux 的容器組件的概念。頁面首先是一個標準的 React 組件，其次它通過 react-redux 封裝成容器組件從而具備和 Redux 交互的能力。

頁面是導航的基本模塊單元，同時也是同一功能相關 UI 的容器，這種符合傳統(tǒng) Web 開發(fā)方式的概念有助于讓項目結構更容易理解。

每個 action 一個獨立文件

使用 Redux 來管理狀態(tài)，就需要進行 action 和 reducer 的開發(fā)。在官方示例以及幾乎所有的教程中，所有的 action 都放在一個文件，而所有的 reducer 則放在另外的文件。這種做法易于理解但是不具備很好的可擴展性，而且當項目復雜后，action 文件和 reducer 文件都會變得很冗長，不易開發(fā)和維護。

因此我們使用每個 action 一個獨立文件的模式：每個 Redux 的 action 和對應的 reducer 放在同一個文件。使用這個做法的另一個原因是我們發(fā)現(xiàn)每次創(chuàng)建完 action 幾乎都需要立刻創(chuàng)建 reducer 對其進行處理。把它們放在同一個文件有利于開發(fā)效率和維護。

以開發(fā)一個計數(shù)器組件為例：

為實現(xiàn)點擊“+”號增加1的功能，我們首先需要創(chuàng)建一個類型為 "COUNTER_PLUS_ONE" 的 action ，之后就立刻需要創(chuàng)建對應的 Reducer 來更新 store 的數(shù)據(jù)。官方示例的做法是分別在 actions.js 和 reducer.js 中分別加入相應的邏輯。而使用每個 action 獨立文件的做法，則是創(chuàng)建一個名為 counterPlusOne.js 的文件，加入如下代碼：

 import { 
  COUNTER_PLUS_ONE, 
} from './constants'; 
 
export function counterPlusOne() { 
  return { 
    type: COUNTER_PLUS_ONE, 
  }; 
} 
 
export function reducer(state, action) { 
  switch (action.type) { 
    case COUNTER_PLUS_ONE: 
      return { 
        ...state, 
        count: state.count + 1, 
      }; 
 
    default: 
      return state; 
  } 
}

按我們的經(jīng)驗，大部分的 reducer 都會對應到相應的 action，很少需要跨功能全局使用。因此，將它們放入一個文件是完全合理的，有助于提高開發(fā)效率。需要注意的是，這里定義的 reducer 并不是標準的 Redux reducer，因為它沒有初始狀態(tài)(initial state)。它僅僅是被功能文件夾下的根 reducer 調(diào)用。注意這個 reducer 固定命名為 "reducer"，從而方便其被自動加載。

對于異步 action(通常是遠程 API 請求)，則需要對錯誤信息進行處理，因此在這個文件中有多個標準 action 存在。例如以保存文章為例，在 saveArticle.js 這個 action 文件中，同時存在 saveArticle 和 dismissSaveArticleError 這兩個 action。

如何處理跨功能的 action?

盡管不是很常見，但是有些 action 是可能被多個 reducer 處理的。例如，對于站內(nèi)聊天功能，當收到一條新消息時：

如果聊天框開著，那么直接顯示新消息。
否則，顯示一條通知提示有新的消息。

可見，NEW_MESSAGE 這個 action 類型需要被不同的 reducer 處理，從而能夠在不同的 UI 組件做不同的展現(xiàn)。為了處理這類 action，每個功能文件夾下都有一個 reducer.js 文件，在里面可以處理跨功能的 action。

雖然不同 action 的 reducer 分布在不同的文件中，但它們和功能相關的 root reducer 共同操作同一個狀態(tài)，即同一個 store 分支。因此 feature/reducer.js 具有如下的代碼結構：

import initialState from './initialState'; 
import { reducer as counterPlusOne } from './counterPlusOne'; 
import { reducer as counterMinusOne } from './counterMinusOne'; 
import { reducer as resetCounter } from './resetCounter'; 
 
const reducers = [ 
  counterPlusOne, 
  counterMinusOne, 
  resetCounter, 
]; 
 
export default function reducer(state = initialState, action) { 
  let newState; 
  switch (action.type) { 
    // Put global reducers here 
    default: 
      newState = state; 
      break; 
  } 
  return reducers.reduce((s, r) => r(s, action), newState); 
}

它負責引入不同 action 的 reducer，當有 action 過來時，遍歷所有的 reducer 并結合需要的全局 reducer 來實現(xiàn)對 store 的更新。所有功能相關的 root reducer 最終被組合到全局的 Redux root reducer 從而保證全局只有一個 store 的存在。

需要注意的是，每當創(chuàng)建一個新的 action 時，都需要在這個文件中注冊。因為其模式非常固定，我們完全可以使用工具來自動注冊相應的代碼。Rekit 可以幫助做到這一點：當創(chuàng)建 action 時，它會自動在 reducer.js 中加入相應的代碼，既減少了工作量，又可以避免出錯。

使用單文件 action 的好處

使用這種方式，可以帶來很多好處，比如：

易于開發(fā)：當創(chuàng)建 action 時，無需在多個文件中跳轉(zhuǎn);
易于維護：因為每個 action 在單獨的文件，因此每個文件都很短小，通過文件名就可以定位到相應的功能邏輯;
易于測試：每個 action 都可以使用一個獨立的測試文件進行覆蓋，測試文件中也是同時包含對 action 和 reducer 的測試;
易于工具化：因為使用 Redux 的應用具有較為復雜的技術結構，我們可以使用工具來自動化一些邏輯。現(xiàn)在我們無需進行語法分析就可以自動生成代碼。
易于靜態(tài)分析：全局的 action 和 reducer 通常意味著模塊間的依賴。這時我們只要分析功能文件夾下的 reducer.js，即可以找到所有這些依賴。

React-router 的規(guī)則定義

通常來說，我們會通過一個配置文件定義所有的路由規(guī)則。同樣的，這種方式不具有擴展性，當項目變復雜之后，規(guī)則定義表會變得冗長而復雜。既然我們已經(jīng)以功能為單位進行文件夾的組織，我們同樣可以把功能相關的路由規(guī)則也放到對應文件夾下。因此，我們可以利用 React-router 的 JavaScript API 進行路由規(guī)則的定義，而不是用常見的 JSX 語法。

例如，對于一個簡單論壇程序，主題功能對應的路由定義就放在 features/topic/route.js 中，內(nèi)容如下：

import { 
  EditPage, 
  ListPage, 
  ViewPage, 
} from './index'; 
 
export default { 
  path: '', 
  name: '', 
  childRoutes: [ 
    { path: '', component: ListPage, name: 'Topic List', isIndex: true }, 
    { path: 'topic/add', component: EditPage, name: 'New Topic' }, 
    { path: 'topic/:topicId', component: ViewPage }, 
  ], 
};

所有功能相關的路由定義都被全局的根路由配置自動加載，因此，路由加載器具有如下的代碼模式：

import topicRoute from '../features/topic/route'; 
import commentRoute from '../features/comment/route'; 
 
const routes = [{ 
  path: '/rekit-example', 
  component: App, 
  childRoutes: [ 
    topicRoute, 
    commentRoute, 
    { path: '*', name: 'Page not found', component: PageNotFound }, 
  ], 
}];

可見，這個全局路由加載器負責加載所有 feature 的路由規(guī)則。類似 root reducer，這里的代碼模式也是非常固定的，因此可以借助工具來維護這個文件。當使用 Rekit 創(chuàng)建頁面時，就會自動在此加入路由規(guī)則。

使用工具輔助開發(fā)

由上面的介紹可以看到，開發(fā)一個 React 程序并不容易，即使一個簡單的功能，也需要大量的瑣碎的，但卻非常重要的代碼來確保一個良好的架構，從而讓應用易于擴展和維護，雖然這些周邊代碼和你需要的功能并沒有直接關系。

例如，對于一個論壇程序，需要一個列表界面展示最近發(fā)表的主題，為了做這樣一個頁面，我們通常都需要完成以下步驟：

創(chuàng)建一個名為 TopicList 的 React 組件;
為 TopicList 定義一條路由規(guī)則;
創(chuàng)建一個名為 TopicList.css 的樣式文件，并在合適的位置引入;
使用 react-redux 將 TopicList 組件封裝成容器組件，從而使其可以使用 Redux store;
創(chuàng)建4種不同的 action 類型：FETCH_BEGIN, FETCH_PENDING, FETCH_SUCCESS, FETCH_FAILURE，通常定義在 constants.js;
創(chuàng)建兩個 action：fetchTopicList 和 dismissFetchTopicListError;
在 action 文件中引入類型常量;
在 reducer 中創(chuàng)建4個 swtich case 來處理不同的 action 類型;
在 reducer 文件中引入類型常量;
創(chuàng)建組件的測試文件及其代碼結構;
創(chuàng)建 action 的測試文件及其代碼結構;
創(chuàng)建 reducer 的測試文件及其代碼結構。

天!在正式開始寫論壇邏輯的***行代碼之前，竟然需要做這么多瑣碎的事情。當這樣的事情手動重復了多次之后，我們覺得應該有工具來自動化這樣的事情。為此創(chuàng)建了 Rekit 工具包，可以幫助自動生成這些文件結構和代碼。不同于其它的代碼生成器，Rekit 基于一個相對固定的文件和代碼結構，因此可以做更多的事情，例如：

它知道在哪里以及如何定義路由規(guī)則;
它知道如何生成 action 類型常量;
它知道如何根據(jù) action 名字來生成類型常量;
它知道如何根據(jù) action 類型來創(chuàng)建 reducer;
它知道如何創(chuàng)建有意義的測試案例。

借助于精心維護的工具，我們可以不必關注技術細節(jié)，而只需專注于功能相關的代碼，提高了開發(fā)效率。不僅如此，工具也可以減少錯誤，并在代碼結構，命名，配置等方面維持高度一致性，讓代碼更加容易理解和維護。

Rekit 針對本文提出的 React + Redux 開發(fā)實踐提供了一套工具集，其本身也是可擴展的。你完全可以根據(jù)需要更改代碼模板，或者提供自己的工具，針對自己的項目特性提供便捷的工具來提高開發(fā)效率。

小結

本文主要介紹了如何使用 React，Redux 以及 React-router 來開發(fā)可擴展的 Web 應用。其核心思路有兩個，一是以功能(feature)為單位組件文件夾結構;二是采用每個 action 單獨文件的模式。這樣能夠讓代碼更加模塊化，增加和刪除功能都不會對其它模塊產(chǎn)生太大影響。同時使用 React-router 來幫助實現(xiàn)頁面的概念，讓單頁應用(SPA)也擁有傳統(tǒng) Web 應用的 URL 導航功能，進一步降低了功能模塊間的耦合行，讓應用結構更加清晰直觀。

為了支持這樣的實踐，文中還介紹了 Rekit 工具集，不僅可以幫助創(chuàng)建和配置初始的項目模板，而且還提供了大量實用的工具幫助以文中提到的方式自動生成技術結構，提高了開發(fā)效率。更多的工具介紹可以訪問其官網(wǎng)：http://rekit.js.org。

責任編輯：龐桂玉來源： segmentfault