使用React框架重構百度新聞webapp前端 fis3作為構建工具

百度新聞客戶端 安卓版v6.0.1.0 官方版

• 類型：新聞資訊大?。?i>25.3M語言：中文 評分：10.0
• 標簽：

立即下載

在進行React重構優化的過程中，構建對項目的優化作用必不可少?，F在2016年8月，web前端技術這幾年變化太快，因此一些信息的時效性非常重要，還是把時間寫上比較好。

百度新聞的 webapp 有兩個途徑可以訪問。第一個是用手機瀏覽器訪問 m.baidu.com 點擊搜索框下面的“新聞”鏈接，第二個是下載手機百度app，搜索框下面有個“新聞”鏈接。每天平均的PV，大概接近1億。

為何要重構？

重構一個項目需要很多條件的支持，但是最終的目的，是為了：第一減少維護和二次開發的成本、第二提高產品的用戶體驗或完善功能，兩者至少要符合一個，否則沒必要重構。不是為了重構而重構，為了技術而重構。

要重構一個項目，特別是一個比較復雜的項目，是需要一些條件的，否則一般都會維護現有版本的產品。比如好多公司的app、網站做的很炫很漂亮，而公司內部的erp、oa、cms等系統都用著10多年前的代碼。新聞webapp雖然看似就是一個很簡單的新聞列表、新聞分類、新聞內容頁，但是詳細分析起來還是蠻復雜的?？偨Y起來，重構新聞webapp的條件有這么幾個：

目前代碼比較混亂、代碼之間耦合太多，從2011年做完這一版開始，經歷了好幾個人維護；

框架比較老（backbone + zepto），已經落伍，使得維護人員很沒有認同感；

那段時間產品經理的需求不是很多，開發人員正好有大量的時間；

以上原因中，第三個是最重要的，否則大家都每天加班很晚，誰會再去考慮重構這事兒？既然有時間，那就做吧！我就主動跟我們組長提出了這個事兒，得到他的贊同之后，我們就就開始了下面的內容。

選擇靠譜的技術框架

重構的第一步就是選擇一個比較靠譜的前端框架?，F階段你如果要做一個webapp，再說什么框架都不用，就用zepto.js，那就out了。這并不是為了炫耀技術或者為了用而用，選用一個靠譜的框架，真的會從設計、開發、維護這幾個方面都會增加效率降低成本。

現階段前端框架可選的有以下幾個：

angular

vue

react

angular我們一開始就直接放棄了。第一，因為它自己太過于強大，什么事兒都自個干了，不利于配置和擴展；第二，它的學習成本相對于其他兩個算最高的了，代碼畢竟不是自己一個人寫，而且寫完了也不一定后期誰維護呢，學習成本盡量越低越好；第三，它都快升級2.0版本了，當時2.0沒有正式發布，不是已經有beta版本，而且使用了typescript，學習成本就更高了。

下面，就到了vue和react的選擇了。這兩者我當時都是了解各大概，做過一些demo，但是都沒有在項目中實際用過。于是我花了大概一周多的時間做了一個調研，即分別用vue和React做了一個很粗糙的、簡化版的新聞webapp的demo，然后兩者做了一下對比。后來沒有發現兩者有太多的懸殊，可能有些細節的習慣上仁者見仁，無論是使用React還是Vue都能很高效、清晰的完成既定功能，學習成本也都不高。

關于React和Vue的入門教程，介紹兩個很不錯的視頻教程《 vuejs入門基礎》、《React入門》《React實戰–打造畫廊應用》

但是，最后還是選擇了React，理由就是React生態更大。確切的說，應該是選擇了React + React-router + Redux的技術框架，與之對應的是Vue + Vue-router + Vuex

做技術，框架的生態很重要。選擇對了，以后的升級就順風順水，選擇錯了，就會很糾結很難受。果不其然，沒過多久，手機百度的app團隊就成了研究React Native的技術小組，由于我當時早早的熟悉了React，還給他們當了幾次老師[偷笑]。

驗證技術框架的性能問題

選擇完技術框架之后，還有兩個重要的問題有待于驗證。

低版本android是否流暢

拿我們之前用React做的那個demo，在未經過優化的情況下，使用一些低版本的手機進行驗證，結果發現瀏覽器運行的效果還算是流暢，最后優化之后的流暢度會好一些。但是中途遇到兩個其他問題，就此記錄一下。

flex兼容性問題：本來利用flex布局，結果如果要使用flex-wrap做換行的話，有些瀏覽器就不支持了，最典型的就是android的UC瀏覽器；

fetch 的兼容性問題：高級瀏覽器默認支持fetch了，但是低版本（如 ios6）還不支持，需要借助npm install es6-promise這個庫來做兼容。

React比Vue重，如何讓首屏更“輕”

用React開發webapp肯定是SPA應用，網頁一加載肯定會把系統中用到的所有的js、css都加載下來，但是這樣會不會導致首屏時間會很慢？帶著這個疑問，我們做了一個使用fis3做異步加載的demo。demo很簡單，就一個home頁（列表頁）、detail頁、about也，很簡單的一個demo，最關鍵的是下面的fis-conf.js的配置。

下面這個配置的意思是：根據不同的頁面，打包成不同的文件。例如，針對 home頁打包成一個home-third.js和home-app.js，針對about頁打包成about-third.js和about-app.js……這樣，訪問哪個頁面就動態加載相應的js，暫時訪問的不到的頁面，其js就先不加載。這樣來提高性能。

（以下代碼如果看不懂，可以先看下一節介紹fis3配置的內容，那里會有這塊的解釋）

后來直到上線，這個分頁面加載資源也沒用上。原因如下：

配置有點復雜，針對不同router都得配置

經過壓縮之后，third.js才80kb，app.js不到50kb，而且third.js一般是強緩存的，文件已經很小了，沒必要做分屏加載

選擇靠譜的構建工具

在公司內部做項目，當然盡量選用公司自己的框架，而百度的 fis3 那會兒已經基本成熟了，有了400+的插件，支持我們當時的React重構是問題不大了。而且，當時已經有人拿fis3做過構建React的重構，還分享了經驗——如何用 fis3 來開發 React?

fis3 是一個很不錯的構建工具，至少我們在使用過程中還比較滿意。除了基本功能，它的動態假數據模擬、發布到測試機這些功能非常實用，詳情請看官網文檔。但是它最大的問題是生態、圈子上還沒有webpack、gulp大，因此用的人少，用的人越少了生態就越小。

為項目選擇打包工具，除了基本功能（打包、壓縮、合并、編譯less等語法糖、生成md5后綴等等），以下幾點是最必須考慮的內容。

編譯 React 的 .jsx格式和 ES6 語法

支持 npm 生態，支持js的模塊管理

動態引用css和圖片（因為要用組件化開發，組件需要的css要在組件中引用）

按需打包js

模擬假數據，運行代碼

支持多種編譯模式，例如dev模式下不壓縮代碼、方便調試，而publish模式下壓縮代碼、壓縮資源

下面挨著說明一下，以上幾點使用fis3時如何配置的，也權當幫助公司宣傳一下國產前端編譯神器——fis3

注意：以下所提到的fis3的配置，都要寫在./fis-conf.js代碼中，這是fis3的規則，可以去查閱官網的文檔。另外，以下代碼注釋中提示要npm install ... --save-dev安裝的插件，你都可以在 github.com 上找到。

編譯 React 的 .jsx格式和 ES6 語法

一般情況下，編譯ES6都用babel，編譯jsx也有相應的工具，但是沒成想這兩個只需要用typescript這一插件就搞定了。速度還要快，不過編譯打包，速度慢一點也沒關系，不考慮這個因素。但是使用typescript確實很方便。

支持 npm 生態，支持js的模塊管理

以下配置即可是的fis3支持npm生態，并且選擇使用commonjs的模塊化方案。這樣我們使用 npm install react --save 之后，在js代碼中，就直接可以使用import * as React from 'react'了，符合目前js的主流寫法。

動態引用css和圖片

前端現在都是組件化開發的思路，一個項目中可能需要很多css代碼，但是一個組件中，就只引用它自己需要的代碼，然后構建工具再將所有組件引用的css文件合并起來，一起給最終的頁面——這是組件化中使用css的思路。

使用以下配置，我們可以在js文件中直接引用css和圖片文件，跟webpack中使用相似。如果使用ES6語法，引用css時寫import './style.css'，引用圖片時寫 import * as url from '../img/abc.png'

按需打包js

因為是組件化開發，因此項目中所有的圖片都是零散的放在各個組件里面的，因此最終打包之后，要將所有的圖片都打包到一個統一的目錄下，方便管理

最終打包完成的時候，我們要將項目中用到的所有代碼都打包成以下幾個文件：

app.js 程序員手寫出來的業務代碼，后期的二次開發或者維護調整比較頻繁，單獨打包成一個文件；

third.js 第三方插件的代碼，例如 React Redux 等，后期幾乎不調整，單獨打包成一個文件，可直接使用http強緩存，提高性能；

aio.css 所有的css文件

lib.js 直接以<script>方式寫在html頁面上的幾個js文件，都打包成 lib.js ，減少http請求

具體配置查看如下代碼，注釋中寫的也非常清楚了

模擬假數據，運行代碼

大部分情況下，開發的代碼要查看效果都是啟用 fis3 server start 然后在本地瀏覽器打開 127.0.0.1:8080 來自測的，而此時本地是沒有服務器端的接口的，例如本地頁面中有一個/news?tn=gethotnews這個ajax請求（舉例用，實際上根本沒有 gethotnews 這個接口名稱），默認會請求127.0.0.1/news?tn=gethotnews，是會返回404的。那這時候怎么辦呢？

提前你要查閱fis3關于假數據模擬的 文檔說明

選擇一，你可以為/news?tn=gethotnews這個接口準備一個靜態的json文件，文檔中說過了。但是新聞webapp的接口實在是太多了，為每個接口都準備一下，耗費很多工作量，而且萬一接下來接口返回的數據結構有變化，還得跟著改，麻煩。因此我們選擇第二種。

選擇二，如果在本地訪問有/news?tn=gethotnews，通過借助fis3的一些功能，能直接返回線上m.news.baidu.com/news?tn=gethotnews的數據，這樣是不是就一步搞定了！下面說說該如何操作。

首先，新建一個./config/server.conf的文件，內容如下。意思是，只要發出去的網絡請求的url符合^\/news.*$這個正則規則，就交給/test/data.js來處理，具體如何處理，往下看。

其次，新建一個./test/data.js的文件，內容我就不能直接粘貼了，意思就是通過nodejs來抓取線上的結果。這樣就完成了動態獲取線上數據的功能。

此外，fis-conf.js中還需如下配置，意思是./test和./config兩個文件夾下的內容，打包時候要按照既定的路徑打包。即 ./test/data.js這個路徑，打包之后還是./test/data.js這個路徑。

支持多種編譯模式

這個需求也是我們開發中必須的。例如，我們要為上線打包文件時，需要讓js有md5后綴（為了方便緩存），文件要壓縮到最??；而我們要自測打包的時候，就無需md5后綴（否則一天下來產生很多冗余文件），文件不要壓縮（否則無法在瀏覽器調試）。

fis3的文檔中有介紹，我們可以使用fis.media來滿足我們的需求。如下配置，使用fis.media('publish').match配置了js和css的壓縮功能，而解析less的時候沒有用fis.media

當運行fis3 release的時候，fis3只會匹配沒有配置fis.media的配置項，例如解析less功能。當運行fis3 release publish的時候，fis3既會匹配fis.media('publish').match又會匹配fis.match，即less也解析了、js和css也都壓縮了。

當然，你還可以自己定義很多media，例如fis.media('test')。但是不要用fis.media('dev')，因為fis3默認的media就是dev，算是個保留字。

是否使用 npm 生態

其實這里不應該是一個問題，不過當時有一個小小的糾結，就順便在這里記錄一下吧。

解決的問題

我們現在主流的開發方式，引用 React 一般都是 npm install react --save，然后在代碼中直接 import * as React from 'react'來引用。這就是所謂的“npm 生態”，即使用 npm 來管理依賴。

但是當時就這個用法，出現過一個糾結，即這樣依賴，我們打包的third.js文件中，會有很多define語句，都是和React相關的。因為用 npm 安裝的 React 也是有好多零散的文件組成的，并不是就一個 React.js。然后，就開始擔心這么多“冗余代碼”會不會導致代碼文件大很多，就開始想其他解決方法（其實最后根本不是問題）

解決方案

最后想出來的解決方法很有意思，就是要下載一個react.min.js然后放在如./lib的一個文件夾中，然后在代碼中使用import * as React from '../../lib/react.min.js'這樣用。

這樣是能解決很多個define的問題了，因為沒必要define了，只有一個react.min.js文件，還define個什么勁？

后來

后來，這個解決方案還是被我否決了，當時也沒想出什么壓倒式的理由，但是有一個原因——沒人這么用！大家都在基于npm生態，社區中的寫法基本已經固定了，現在卻不這么寫，自己獨創一個寫法，那樣會越走越窄。哪怕會有那么一點的不完善，我也要按照大家通用的格式來，不要獨創。

其實后來想了一下，按照解決方案那種使用react.min.js的方式，也是有很多問題的。例如，開發模式下也用.min.js那樣就沒有React自帶的提示、警告功能了，萬一忽略了什么性能問題，沒有提示和警告，可就麻煩打了。再例如，這樣一來就沒有版本管理了，前端框架更新很快，版本管理很重要。

最后，我們發下經過各種壓縮，最后的third.js都不到100kb，完全滿足我們的要求————這個年代，真的用不著自己去創新。

系統設計（邏輯）

要降低系統設計的復雜度，前端目前最好的方式就是組件化。將系統劃分成若干個頁面，然后將每個頁面都劃分成若干個組件，還要抽象出多個頁面中都會用到的通用組件，這是第一步。接下來要看組件和組件之間如何傳遞數據，即數據管理和狀態管理該如何做。下面我們就從這兩個方面來分先一下新聞webapp該如何設計。

從 router 到 page 再到 component

下圖是一個最基本的設計理念，實際項目中也是按照這個來細化、擴展最后落地執行的。即，先給頁面劃分組件，然后組件構成頁面，最后頁面匹配路由。如下圖：

將這個落實到頁面上，就是這個效果

但是最后在開發過程中忽略了一個問題，就是一些復雜頁面（例如新聞NBA頻道頁，用瀏覽器模擬手機查看效果），光這種“頁面 - 組件”的形式是不夠的，應該在加一個subpage層，這樣就擴展性更好一些了。如下圖：

總結：一個項目總會遇到個別的比較復雜的頁面，因此這種page - subpage - component會更加合理一些，其中的subpage在不需要的時候省略掉就是了。

智能組件 VS 木偶組件

在 React + Redux 結合作為前端框架的時候，提出了一個將組件分為“智能”和“木偶”兩種

智能組件：它是數據的所有者，它擁有數據、且擁有操作數據的action，但是它不實現任何具體功能。它會將數據和操作action傳遞給子組件，讓子組件來完成UI或者功能。這就是智能組件，也就是項目中的各個頁面。

木偶組件：它就是一個工具，不擁有任何數據、及操作數據的action，給它什么數據它就顯示什么數據，給它什么方法，它就調用什么方法，比較傻。這就是木偶組件，即項目中的各個組件。

因此，數據在page層獲取、數據的操作和處理在page層定義，組件就是傻傻的知道執行和顯示就行了，各操各的心。這種設計也整好符合目前無論是Vue、augular還是React提倡的基于數據驅動的設計理念——程序定義好Model和View的關系，剩下的業余處理只需要關心數據變化，View的變化由框架自動執行，無需像jquery時代再去手動操作DOM。

數據管理

下面看一下數據在系統中是如何傳遞的。這里的數據分為兩種：

第一種可以稱之為“系統數據”，和業務無關的，一般任何系統中都會有。例如用戶id、用戶頭像、配置信息等，這個的特點就是符合單例模式，全局共用一套

第二種可以稱之為“業務數據”，每個頁面都可能不一樣。如在娛樂頻道需要的是娛樂新聞列表，而到了軍事頻道就需要軍事新聞的列表了，再到新聞詳情頁就需要新聞的內容了

針對這兩種不同的數據，當然要分開處理。針對第一種“系統數據”，系統一初始化就立即獲取，然后交給Redux做管理，這也符合Redux的特點。而針對第二種“業務數據”，那就什么時候用，就什么時候獲取。

代碼架構（物理）

使用React + Redux設計代碼結構，目前方式都比較統一，基本都是按照以下方式來設計，這些在github等社區都能找到相似的結構。

以上目錄中，app/components和app/container是開發中修改最多的目錄。app/container里面定義的都是頁面，即智能組件，只關心數據，功能比較單一，因此結構也比較簡單

但是針對組件app/components來說，要顯示樣式，當然就需要css和圖片，文件類型比較多。因此，要按照如下方式定義組件

即，用一個文件夾來表示單個組件，里面的index.jsx是業務和模板代碼，style.less是樣式，img/文件夾放圖片文件。這樣的話，可以把每個組件都作為一個整體來管理，而且引用的時候也比較方便，例如import LoadMore from '../../app/components/LoadMore'就可以了——目錄名即組件的名字。

雖然我沒法將源碼的目錄結構截圖出來分享給大家，但是我們實際開發中的目錄結構基本是按照這個方式來做的，可能就是細節上因此會因為業務的問題做了特殊處理，但是設計理念上是一樣的。

開發 - 如何多人協作開發

上文已經描述了一些基本配置和系統設計的解決方案，接下來即可進入開發。由于不是一個人做，因此必須考慮如何高效率的多人協作開發。其實這不是一個技術問題，這里就簡單寫一下這方面的心得體會吧。

定義階段

提前定義好代碼結構，統一各個文件夾的作用

提前設計Router規則，以及和頁面的對應關系

提前抽象出可能在多個頁面中通用的組件，創建文件夾（占位置）

討論確定每個頁面都如何拆分組件，統一設計思路

開發階段

每人開發不同的頁面，遇到頁面單獨用的組件，即自行開發；

遇到多頁面公用的組件，先同步組內開發進度，有則直接用，沒有則自己開發；

每裝配好一個組件，都提交一次代碼，隨時開發、隨時提交、隨時合并；

心得：如果你要參與一個重構項目，你只需要按部就班發揮自己的技術能力即可，按照規則編碼、測試、提交代碼等。但是如果你要自己組織、規劃一次系統重構，考慮的事情那就太多了。除了頂住外在的壓力之外，還得考慮如何讓這件事兒更快、更穩定的運行起來。

開發 - 自測

使用fis3作為構建工具，其實使用fis3 server start即可啟動本機的服務，然后進行測試。但是像新聞這種產品，它的任何頁面都需要獲取數據再展示，因此測試的時候需要一些模擬的或者真實的數據，這個fis3也支持，在上文介紹fis3配置的時候已經說明了。

但是這種本機運行、并用fis3動態假數據模擬的情況有一個問題：它沒法模擬登錄的情況，http請求中也沒有登錄狀態下的那些cookies信息，這就會影響很多功能的測試。因為新聞的許多功能是需要登錄才能運行的，例如個人收藏、訂閱頻道、評論、點贊等。

最終想到的一個辦法是將代碼放在公司內部的一臺測試機上，然后通過測試機訪問，這樣就可以獲取登錄信息。因此這里介紹一下如何使用fis3將代碼發布到測試機上。fis-conf.js中做如下配置：

配置完了之后，執行fis3 release remote，它就會執行編譯，并且將編譯后的文件傳上去。然后再在測試機上配置一個服務，支持頁面的訪問即可。

開發 - 代碼檢查

代碼檢查是開發環境中非常重要的一步，其實這塊的配置很簡單，之所以單獨列出來，就是為了體現它在開發過程中（特別是多人協作）的重要性。

項目中使用eslint做檢查，其主要配置文件有兩個。.eslintignore定義了忽略哪些文件的檢查，例如我們要忽略一個第三方插件的代碼檢查

還有一個.eslintrc.json定義了代碼的檢查規則，本項目的檢查規則相對比較寬松，配置如下。其配置項的意義，在網絡上可以輕松查詢到。

最后，我們將檢查代碼的命令封裝進package.json中，如下代碼。這樣，在檢查的時候，只需要運行npm run lint這個簡單命令即可

目前只是軟性的規定，在git commit之前必須做檢查，如果開發人員忽略了，也能將代碼提交上。接下來將考慮將代碼檢查強制做到git-hook里面，即git commit之前必須要檢查通過，否則無法提交。

打包 & 提測

上文說過，自測的時候，發布的代碼是未經過壓縮、也未加md5后綴的，而且直接將代碼發布到服務器的目錄即可，無需存到指定目錄。但是要打包出一個目錄，然后將文件提交給測試人員，就和自測不一樣了。

首先，打包的文件要壓縮、要加md5后綴（上文講述fis3的配置的時候已經說過）；其次，要講文件打包到指定目錄，這里定義將文件打包到./release目錄下；第三，fis3的默認release功能還會將開發環境的源文件一起打包了，這些是不需要的（僅僅需要合并出來的代碼即可，合并的代碼在./release/static目錄下）。將以上這些需求一整合，寫一個復雜的命令一起放在package.json中

這樣，執行npm run publish即可生成一個./release文件夾，里面包含了最終的模板文件、編譯之后的js和css、以及處理之后的圖片文件。目錄結構如下。最終，將這個文件夾提交給測試人員部署即可。每個公司都有自己的提測流程，百度內部流程這里就不說了。

測試過程中，qa可能會有反饋bug，至于如何修復bug，以及如何進行二次開發和維護，我都寫了一個說明文檔（僅供百度內網訪問），規定了每個步驟該如何執行。

上線

測試完了之后要上線，每個公司的上線步驟也都不盡相同，有的高級一些，有的low一些，這里就不管了。

上線之后注意如何及時快速的回滾，這一點很重要。

總結

洋洋灑灑寫了好多，最后做一個簡單的總結。

系統重構的目的永遠都是為了后面減少開發成本、提高系統性能和穩定性，這是公司或部門需要的結果。對于實際執行的個人來說，參與或發起重構項目，是對自己如何掌控一個產品前端設計和架構的一次很好的機會，會對自己有很大的能力提升。重構過程中會遇到一些預想不到的問題，思考在過程中解決這些問題，對自己又是另一方面的能力提升。因此，好的東西，都是雙贏的。

待優化

繼續壓榨性能：無論是通過資源的懶加載，還是使用Immutable.js做不可變數據，都要讓性能達到最優

完善一些設計不足的地方：例如目前的page - components 改為到 page - subpage - components的方式

接下來

選擇React框架肯定要再試圖往兩個方向來攻：

服務器端渲染

React Native

最后

現在一言不合就秀配置打包代碼～