現(xiàn)在是前端開(kāi)發(fā)***的時(shí)代，有太多很好的框架和工具幫你更好的實(shí)現(xiàn)復(fù)雜需求;同時(shí)又是最困難的時(shí)代，因?yàn)樾枰莆仗嗟目蚣芎凸ぞ摺Ｈ绾卫煤酶鞣N框架來(lái)提高前端開(kāi)發(fā)質(zhì)量是大家都在探索的問(wèn)題。本文就將介紹如何使用 React 及其相關(guān)技術(shù)，來(lái)進(jìn)行實(shí)際前端項(xiàng)目的開(kāi)發(fā)。因?yàn)橹饕榻B如何將技術(shù)用于實(shí)踐，所以希望讀者已經(jīng)對(duì)相關(guān)概念已經(jīng)有一定的了解。

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

[[174836]]

其實(shí)無(wú)論使用什么樣的技術(shù)，一個(gè)理想中的 Web 項(xiàng)目大概都需要考慮以下幾個(gè)方面：

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

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

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

React

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

Redux

Redux 是 JavaScript 程序狀態(tài)管理框架。盡管是一個(gè)通用型的框架，但是和 React 在一起能夠更好的工作，因?yàn)楫?dāng)狀態(tài)變化時(shí)，React 可以不用關(guān)心變化的細(xì)節(jié)，由虛擬 DOM 機(jī)制完成優(yōu)化過(guò)的UI更新邏輯。

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

React-router

即使對(duì)于一個(gè)簡(jiǎn)單的應(yīng)用，路由功能也是極其重要的。正如傳統(tǒng) Web 程序用頁(yè)面來(lái)組織不同的功能模塊，由不同的 URL 來(lái)區(qū)分和導(dǎo)航，單頁(yè)應(yīng)用使用 Router 來(lái)實(shí)現(xiàn)同樣的功能，只是在前端進(jìn)行渲染而不是服務(wù)器端。React 應(yīng)用的“標(biāo)準(zhǔn)”路由方案就是使用 React-router。

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

其它需要的技術(shù)

正如前面提到的，開(kāi)發(fā)前端應(yīng)用需要很多周邊技術(shù)，這進(jìn)一步增加了前端開(kāi)發(fā)的門檻，例如：

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

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

簡(jiǎn)單介紹了相關(guān)技術(shù)，下面我們來(lái)看如何去構(gòu)建可擴(kuò)展的 Web 項(xiàng)目。

按功能(feature)來(lái)組織文件夾結(jié)構(gòu)

無(wú)論是 Flux 還是 Redux，提供的官方示例都是以技術(shù)邏輯來(lái)組織文件夾的，例如，下面是 Redux 的 Todo 示例應(yīng)用的文件夾結(jié)構(gòu)：

 雖然這種模式在技術(shù)上很清晰，在實(shí)際項(xiàng)目中卻有很大的缺點(diǎn)：

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

因此，我們使用按功能來(lái)組織文件夾的方式，即功能相關(guān)的代碼放到一個(gè)文件夾。例如，對(duì)于一個(gè)簡(jiǎn)單論壇程序，可能包含 user，topic，comment 這么幾個(gè)核心功能。

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

 這種文件夾結(jié)構(gòu)在功能上而非技術(shù)上對(duì)代碼邏輯進(jìn)行區(qū)分，使得應(yīng)用具有更好的擴(kuò)展性，當(dāng)增加新的功能時(shí)，只需增加一個(gè)新的文件夾即可;刪除功能時(shí)同理。

使用頁(yè)面(Page)的概念

前面提到了路由是當(dāng)今前端應(yīng)用的不可缺少的部分之一，那么對(duì)應(yīng)到組件級(jí)別，就是頁(yè)面組件。因此我們?cè)陂_(kāi)發(fā)的過(guò)程中，需要明確定義頁(yè)面的概念：

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

頁(yè)面是導(dǎo)航的基本模塊單元，同時(shí)也是同一功能相關(guān) UI 的容器，這種符合傳統(tǒng) Web 開(kāi)發(fā)方式的概念有助于讓項(xiàng)目結(jié)構(gòu)更容易理解。

每個(gè) action 一個(gè)獨(dú)立文件

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

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

以開(kāi)發(fā)一個(gè)計(jì)數(shù)器組件為例：

 為實(shí)現(xiàn)點(diǎn)擊“+”號(hào)增加1的功能，我們首先需要?jiǎng)?chuàng)建一個(gè)類型為 "COUNTER_PLUS_ONE" 的 action ，之后就立刻需要?jiǎng)?chuàng)建對(duì)應(yīng)的 Reducer 來(lái)更新 store 的數(shù)據(jù)。官方示例的做法是分別在 actions.js 和 reducer.js 中分別加入相應(yīng)的邏輯。而使用每個(gè) action 獨(dú)立文件的做法，則是創(chuàng)建一個(gè)名為 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)驗(yàn)，大部分的 reducer 都會(huì)對(duì)應(yīng)到相應(yīng)的 action，很少需要跨功能全局使用。因此，將它們放入一個(gè)文件是完全合理的，有助于提高開(kāi)發(fā)效率。需要注意的是，這里定義的 reducer 并不是標(biāo)準(zhǔn)的 Redux reducer，因?yàn)樗鼪](méi)有初始狀態(tài)(initial state)。它僅僅是被功能文件夾下的根 reducer 調(diào)用。注意這個(gè) reducer 固定命名為 "reducer"，從而方便其被自動(dòng)加載。

對(duì)于異步 action(通常是遠(yuǎn)程 API 請(qǐng)求)，則需要對(duì)錯(cuò)誤信息進(jìn)行處理，因此在這個(gè)文件中有多個(gè)標(biāo)準(zhǔn) action 存在。例如以保存文章為例，在 saveArticle.js 這個(gè) action 文件中，同時(shí)存在 saveArticle 和 dismissSaveArticleError 這兩個(gè) action。

如何處理跨功能的 action?

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

1. 如果聊天框開(kāi)著，那么直接顯示新消息。
2. 否則，顯示一條通知提示有新的消息。

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

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

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

它負(fù)責(zé)引入不同 action 的 reducer，當(dāng)有 action 過(guò)來(lái)時(shí)，遍歷所有的 reducer 并結(jié)合需要的全局 reducer 來(lái)實(shí)現(xiàn)對(duì) store 的更新。所有功能相關(guān)的 root reducer 最終被組合到全局的 Redux root reducer 從而保證全局只有一個(gè) store 的存在。

需要注意的是，每當(dāng)創(chuàng)建一個(gè)新的 action 時(shí)，都需要在這個(gè)文件中注冊(cè)。因?yàn)槠淠Ｊ椒浅９潭?，我們完全可以使用工具?lái)自動(dòng)注冊(cè)相應(yīng)的代碼。Rekit 可以幫助做到這一點(diǎn)：當(dāng)創(chuàng)建 action 時(shí)，它會(huì)自動(dòng)在 reducer.js 中加入相應(yīng)的代碼，既減少了工作量，又可以避免出錯(cuò)。

使用單文件 action 的好處

使用這種方式，可以帶來(lái)很多好處，比如：

1. 易于開(kāi)發(fā)：當(dāng)創(chuàng)建 action 時(shí)，無(wú)需在多個(gè)文件中跳轉(zhuǎn);
2. 易于維護(hù)：因?yàn)槊總€(gè) action 在單獨(dú)的文件，因此每個(gè)文件都很短小，通過(guò)文件名就可以定位到相應(yīng)的功能邏輯;
3. 易于測(cè)試：每個(gè) action 都可以使用一個(gè)獨(dú)立的測(cè)試文件進(jìn)行覆蓋，測(cè)試文件中也是同時(shí)包含對(duì) action 和 reducer 的測(cè)試;
4. 易于工具化：因?yàn)槭褂?Redux 的應(yīng)用具有較為復(fù)雜的技術(shù)結(jié)構(gòu)，我們可以使用工具來(lái)自動(dòng)化一些邏輯。現(xiàn)在我們無(wú)需進(jìn)行語(yǔ)法分析就可以自動(dòng)生成代碼。
5. 易于靜態(tài)分析：全局的 action 和 reducer 通常意味著模塊間的依賴。這時(shí)我們只要分析功能文件夾下的 reducer.js，即可以找到所有這些依賴。

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

通常來(lái)說(shuō)，我們會(huì)通過(guò)一個(gè)配置文件定義所有的路由規(guī)則。同樣的，這種方式不具有擴(kuò)展性，當(dāng)項(xiàng)目變復(fù)雜之后，規(guī)則定義表會(huì)變得冗長(zhǎng)而復(fù)雜。既然我們已經(jīng)以功能為單位進(jìn)行文件夾的組織，我們同樣可以把功能相關(guān)的路由規(guī)則也放到對(duì)應(yīng)文件夾下。因此，我們可以利用 React-router 的 JavaScript API 進(jìn)行路由規(guī)則的定義，而不是用常見(jiàn)的 JSX 語(yǔ)法。

例如，對(duì)于一個(gè)簡(jiǎn)單論壇程序，主題功能對(duì)應(yīng)的路由定義就放在 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 }, 
  ], 
};  

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

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 }, 
  ], 
}];  

可見(jiàn)，這個(gè)全局路由加載器負(fù)責(zé)加載所有 feature 的路由規(guī)則。類似 root reducer，這里的代碼模式也是非常固定的，因此可以借助工具來(lái)維護(hù)這個(gè)文件。當(dāng)使用 Rekit 創(chuàng)建頁(yè)面時(shí)，就會(huì)自動(dòng)在此加入路由規(guī)則。

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

由上面的介紹可以看到，開(kāi)發(fā)一個(gè) React 程序并不容易，即使一個(gè)簡(jiǎn)單的功能，也需要大量的瑣碎的，但卻非常重要的代碼來(lái)確保一個(gè)良好的架構(gòu)，從而讓?xiě)?yīng)用易于擴(kuò)展和維護(hù)，雖然這些周邊代碼和你需要的功能并沒(méi)有直接關(guān)系。

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

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

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

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

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

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

小結(jié)

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

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