【原標題：fetch：大前端如何與Node結合 為何差距越來越大】前端應用越來越復雜，技術框架不斷變化，如何成為一位優秀的前端工程師，應對更大的挑戰？今天，阿里前端技術專家會影結合實際工作經驗，沉淀了五項重要方法，希望能對你的職業發展、團隊協作有所啟發。來源 | 阿里技術責編 | Rainie Liu

過去一年，阿里巴巴新零售事業群支撐的數據相關業務突飛猛進，其中兩個核心平臺級產品代碼量急速增長，協同開發人員增加到數十人。

由于歷史原因，開發框架同時基于 React 和 Angular，考慮到產品的復雜性、人員的短缺和技術背景各異，我們嘗試了各種方法打磨工具體系來提升開發效率，以下分享五點。

一、基于 Redux 的狀態管理從 2013 年 React 發布至今已近 6 個年頭，前端框架逐漸形成 React/Vue/Angular 三足鼎立之勢。幾年前還在爭論單向綁定和雙向綁定孰優孰劣，現在三大框架已經不約而同選擇單向綁定，雙向綁定淪為單純的語法糖。框架間的差異越來越小，加上 Ant-Design/Fusion-Design/NG-ZORRO/ElementUI 組件庫的成熟，選擇任一你熟悉的框架都能高效完成業務。

那接下來核心問題是什么？我們認為是狀態管理。簡單應用使用組件內 State 方便快捷，但隨著應用復雜度上升，會發現數據散落在不同的組件，組件通信會變得異常復雜。我們先后嘗試過原生 Redux、分形 Fractal 的思路、自研類 Mobx 框架、Angular Service，最終認為 Redux 依舊是復雜應用數據流處理最佳選項之一。

慶幸的是除了 React 社區，Vue 社區有類似的 Vuex，Angular 社區有 NgRx 也提供了幾乎同樣的能力，甚至 NgRx 還可以無縫使用 redux-devtools 來調試狀態變化。

無論如何優化，始終要遵循 Redux 三原則：

這三個問題我們是通過自研 iron-redux 庫【1】來解決，以下是背后的思考：

如何組織 Action？

action type 需要全局惟一，因此我們給 action type 添加了 prefix，其實就是 namespace 的概念；

為了追求體驗，請求（Fetch）場景需要處理 3 種狀態，對應 LOADING/SUCCESS/ERROR 這 3 個 action，我們通過 FetchTypes 類型來自動生成對應到 3 個 action。

如何組織 Store/Reducer？

reducer 和 view 不必一一對應，應用中同時存在組件樹和狀態樹，按照各自需要去組織，通過 connect 來綁定狀態樹的一個或多個分支到組件樹；

通過構造一些預設數據類型來減少樣板代碼。對于 Fetch 返回的數據我們定義了 AsyncTuple 這種類型，減少了樣板代碼；

明確的組織結構，第 1 層是 ROOT，第 2 層是各個頁面，第 3 層是頁面內的卡片，第 4 層是卡片的數據，這樣劃分最深處基本不會超過 5 層。

最終我們得到如下扁平的狀態樹。雖龐大但有序，你可以快速而明確的訪問任何數據。

Redux 狀態樹

如何減少樣板代碼？

使用原生 Redux，一個常見的請求處理如下。非常冗余，這是 Redux 被很多人詬病的原因：

使用 iron-redux 后：

代碼量減少三分之二！！

主要做了這 2 點：

引入了預設的 AsyncTuple 類型，就是 {data: [], loading: boolean, error: boolean} 這樣的數據結構；

使用 AsyncTuple.handleAll 處理 LOADING/SUCCESS/ERROR 這 3 種 action，handleAll 的代碼很簡單，使用 if 判斷 action.type 的后綴即可，源碼【2】。

曾經 React 和 Angular 是兩個很難調和的框架，開發中浪費了我們大量的人力。通過使用輕量級的 iron-redux，完全遵循 Redux 核心原則下，我們內部實現了除組件層以外幾乎所有代碼的復用。開發規范、工具庫達成一致，開發人員能夠無縫切換，框架差異帶來的額外成本降到很低。

二、全面擁抱 TypeScriptTypeScript 目前可謂大紅大紫，根據 2018 stateofjs【3】，超過 50% 的使用率以及 90% 的滿意度，甚至連 Jest 也正在從 Flow 切換到 TS【4】。如果你還沒有

使用，可以考慮切換，絕對能給項目帶來很大提升。過去一年，我們從部分使用 TS 變為全面切換到 TS，包括我們自己開發的工具庫等。

TS 最大的優勢是它提供了強大的靜態分析能力，結合 TSLint 能對代碼做到更加嚴格的檢查約束。傳統的 EcmaScript 由于沒有靜態類型，即使有了 ESLint 也只能做到很基本的檢查，一些 typo 問題可能線上出了 Bug 后才被發現。

下圖是一個前端應用常見的 4 層架構。 代碼和工具全面擁抱 TS 后，實現了從后端 API 接口到 View 組件的全鏈路靜態分析，具有了完善的代碼提示和校驗能力。

除了上面講的 iron-redux，我們還引入 Pont 【5】實現前端取數，它可以自動把后端 API 映射到前端可調用的請求方法。

Pont 實現原理：（法語：橋） 是我們研發的前端取數層框架。對接的后端 API 使用 Java Swagger，Swagger 能提供所有 API 的元信息，包括請求和響應的類型格式。Pont 解析 API 元信息生成 TS 的取數函數，這些取數函數類型完美，并掛載到 API 模塊下。最終代碼中取數效果是這樣的：

Pont 實現的效果有：

根據方法名自動匹配 url、method，并且對應到 prams、response 類型完美，并能自動提示；

后端 API 接口變更后，前端相關聯的請求會自動報錯，再也不擔心后端悄悄改接口前端不知曉；

再也不需要前后端接口約定文檔，使用代碼保證前端取數和后端接口定義完全一致。

另外 iron-redux 能接收到 Pont 接口響應數據格式，并推導出整個 Redux 狀態樹的靜態類型定義，Store 中的數據完美的類型提示。效果如下：

最終 TS 讓代碼更加健壯，尤其是對于大型項目，編譯通過幾乎就代表運行正常，也給重構增加了很多信心。

三、回歸 Sass/Less2015 年我們就開始實踐 CSS Modules，包括后來的 styled-components 等，到 2019 年 css-in-js 方案依舊爭論不休，雖然它確實解決了一些 CSS 語言天生的問題，但同時增加了不少成本，新手不夠友好、全局樣式覆蓋成本高漲、偽類處理復雜、與 AntD 等組件庫結合有坑。與此同時 Sass/Less 社區也在飛速發展，尤其是 Stylelint 【6】的成熟，可以通過技術約束的手段來避免 CSS 的 Bad Parts。

全局污染：約定每個樣式文件只能有一個頂級類，如 .home-page{ .top-nav {//}, .main-content{ // } }。如果有多個頂級類，可以使用 Stylelint rule 檢測并給出警告。

依賴管理不徹底。借助 webpack 的 css-loader，已夠用。

JS 和 CSS 變量共享。

關于 JS 和 Sass/Less 變量共享，我們摸索出了自己的解法：

在 scss 文件中，可以直接引用變量：

四、開發工具覆蓋全鏈路2019 年，你幾乎不可能再開發出 React/Angular/Vue 級別的框架，也沒必要再造 Ant-Design/Fusion-Design/Ng-Zorro 這樣的輪子。難道就沒有機會了嗎？

當然有，結合你自身的產品開發流程，依舊有很多機會。下面是常規項目的開發流程圖，任何一個環節只要深挖，都有提升空間。如果你能通過工具減少一個或多個環節，帶來的價值更大。

單拿其中的【開發】環節展開，就有很多可擴展的場景：

一個有代表性的例子是，我們開發了國際化工具 kiwi【7】。它同樣具有 TS 的類型完美，非常強大的文案提示，另外還有：

VS Code 插件 kiwi linter【8】，自動對中文文案標紅，如果已有翻譯文案能自動完成替換；

Shell 命令全量檢查出沒有翻譯的文案，批量提交給翻譯人員；

Codemod 腳本自動實現舊的國際化方案向 Kiwi 遷移，成本極低。

除了以上三點，未來還計劃開發瀏覽器插件來檢查漏翻文案，利用 Husky 在 git 提交前對漏翻文案自動做機器翻譯等等。

未來如果你只提供一個代碼庫，那它的價值會非常局限。你可以參照上面的圖表，開發相應的擴展來豐富生態。如果你是新手，推薦學習下編譯原理和對應的擴展開發規范。

五、嚴格徹底的 Code Review過去的一年，我們一共進行了 1200+ 多次 Code Review(CR)，很多同事從剛開始不好意思提 MR（GitLab Merge Request，Code Review 的一種方式） 到后來追著別人 Review，CR 成為每個人的習慣。通過 CR 讓項目中任何一行代碼都至少被兩人觸達過，減少了絕大多數的低級錯誤，提升了代碼質量，這也是幫助新人成長最快的方式之一。

其中一個項目 MR 截圖

Code Review 的幾個技巧：

No magic；

Explicit not implicit；

覆蓋度比深度重要，覆蓋度追求 100%；

頻率比儀式感重要，坐公交蹲廁所打開手機都可以 Review 別人代碼，不需要專門組織會議；

粒度要盡可能小，一個組件一個方法均可，可以結合 Git Flow；

24h 小時內處理，無問題直接 merge，有問題一定要留 comment，并且提供 action；

對于亟待上線來不及 Review 的代碼，可以先合并上線，上線后再補充 Review；

需要自上而下的推動，具有完善的規范，同時定期總結 Review 經驗來豐富開發規范；

CR 并不只是為了找錯，看到好的代碼，不要吝嗇你的贊美；

本質是鼓勵開發者間更多的溝通，互相學習，營造技術文化氛圍。

總結以上 5 點當然不是我們技術的全部。除此之外我們還實踐了移動端開發、可視化圖表 /WebGL、Web Worker、GraphQL、性能優化等等，但這些還停留在術的層面，未來到一定程度會拿出來分享。

如果你也準備或正在開發復雜的前端應用，同時團隊人員多樣技術背景各異，可以參考以上 5 點，使用 Redux 實現規范清晰可預測的狀態管理，深耕 TypeScript 來提升代碼健壯性和可維護性，借助各種 Lint 工具回歸簡單方便的 CSS，不斷打磨自己的開發工具來保證開發規范高效，并嚴格徹底實行 Code Review 促進人的交流和提升。