在進行React重構優(yōu)化的過程中，構建對項目的優(yōu)化作用必不可少。現(xiàn)在2016年8月，web前端技術這幾年變化太快，因此一些信息的時效性非常重要，還是把時間寫上比較好。
百度新聞的 webapp 有兩個途徑可以訪問。第一個是用手機瀏覽器訪問 m.baidu.com 點擊搜索框下面的“新聞”鏈接，第二個是下載手機百度app，搜索框下面有個“新聞”鏈接。每天平均的PV，大概接近1億。
為何要重構？
重構一個項目需要很多條件的支持，但是最終的目的，是為了：第一減少維護和二次開發(fā)的成本、第二提高產(chǎn)品的用戶體驗或完善功能，兩者至少要符合一個，否則沒必要重構。不是為了重構而重構，為了技術而重構。
要重構一個項目，特別是一個比較復雜的項目，是需要一些條件的，否則一般都會維護現(xiàn)有版本的產(chǎn)品。比如好多公司的app、網(wǎng)站做的很炫很漂亮，而公司內(nèi)部的erp、oa、cms等系統(tǒng)都用著10多年前的代碼。新聞webapp雖然看似就是一個很簡單的新聞列表、新聞分類、新聞內(nèi)容頁，但是詳細分析起來還是蠻復雜的。總結(jié)起來，重構新聞webapp的條件有這么幾個：
目前代碼比較混亂、代碼之間耦合太多，從2011年做完這一版開始，經(jīng)歷了好幾個人維護；
框架比較老（backbone + zepto），已經(jīng)落伍，使得維護人員很沒有認同感；
那段時間產(chǎn)品經(jīng)理的需求不是很多，開發(fā)人員正好有大量的時間；
以上原因中，第三個是最重要的，否則大家都每天加班很晚，誰會再去考慮重構這事兒？既然有時間，那就做吧！我就主動跟我們組長提出了這個事兒，得到他的贊同之后，我們就就開始了下面的內(nèi)容。
選擇靠譜的技術框架
重構的第一步就是選擇一個比較靠譜的前端框架�，F(xiàn)階段你如果要做一個webapp，再說什么框架都不用，就用zepto.js，那就out了。這并不是為了炫耀技術或者為了用而用，選用一個靠譜的框架，真的會從設計、開發(fā)、維護這幾個方面都會增加效率降低成本。
現(xiàn)階段前端框架可選的有以下幾個：
angular
vue
react
angular我們一開始就直接放棄了。第一，因為它自己太過于強大，什么事兒都自個干了，不利于配置和擴展；第二，它的學習成本相對于其他兩個算最高的了，代碼畢竟不是自己一個人寫，而且寫完了也不一定后期誰維護呢，學習成本盡量越低越好；第三，它都快升級2.0版本了，當時2.0沒有正式發(fā)布，不是已經(jīng)有beta版本，而且使用了typescript，學習成本就更高了。
下面，就到了vue和react的選擇了。這兩者我當時都是了解各大概，做過一些demo，但是都沒有在項目中實際用過。于是我花了大概一周多的時間做了一個調(diào)研，即分別用vue和React做了一個很粗糙的、簡化版的新聞webapp的demo，然后兩者做了一下對比。后來沒有發(fā)現(xiàn)兩者有太多的懸殊，可能有些細節(jié)的習慣上仁者見仁，無論是使用React還是Vue都能很高效、清晰的完成既定功能，學習成本也都不高。
關于React和Vue的入門教程，介紹兩個很不錯的視頻教程《 vuejs入門基礎》、《React入門》《React實戰(zhàn)–打造畫廊應用》
但是，最后還是選擇了React，理由就是React生態(tài)更大。確切的說，應該是選擇了React + React-router + Redux的技術框架，與之對應的是Vue + Vue-router + Vuex
做技術，框架的生態(tài)很重要。選擇對了，以后的升級就順風順水，選擇錯了，就會很糾結(jié)很難受。果不其然，沒過多久，手機百度的app團隊就成了研究React Native的技術小組，由于我當時早早的熟悉了React，還給他們當了幾次老師[偷笑]。
驗證技術框架的性能問題
選擇完技術框架之后，還有兩個重要的問題有待于驗證。
低版本android是否流暢
拿我們之前用React做的那個demo，在未經(jīng)過優(yōu)化的情況下，使用一些低版本的手機進行驗證，結(jié)果發(fā)現(xiàn)瀏覽器運行的效果還算是流暢，最后優(yōu)化之后的流暢度會好一些。但是中途遇到兩個其他問題，就此記錄一下。
flex兼容性問題：本來利用flex布局，結(jié)果如果要使用flex-wrap做換行的話，有些瀏覽器就不支持了，最典型的就是android的UC瀏覽器；
fetch 的兼容性問題：高級瀏覽器默認支持fetch了，但是低版本（如 ios6）還不支持，需要借助npm install es6-promise這個庫來做兼容。
React比Vue重，如何讓首屏更“輕”
用React開發(fā)webapp肯定是SPA應用，網(wǎng)頁一加載肯定會把系統(tǒng)中用到的所有的js、css都加載下來，但是這樣會不會導致首屏時間會很慢？帶著這個疑問，我們做了一個使用fis3做異步加載的demo。demo很簡單，就一個home頁（列表頁）、detail頁、about也，很簡單的一個demo，最關鍵的是下面的fis-conf.js的配置。
下面這個配置的意思是：根據(jù)不同的頁面，打包成不同的文件。例如，針對 home頁打包成一個home-third.js和home-app.js，針對about頁打包成about-third.js和about-app.js……這樣，訪問哪個頁面就動態(tài)加載相應的js，暫時訪問的不到的頁面，其js就先不加載。這樣來提高性能。
（以下代碼如果看不懂，可以先看下一節(jié)介紹fis3配置的內(nèi)容，那里會有這塊的解釋）
后來直到上線，這個分頁面加載資源也沒用上。原因如下：
配置有點復雜，針對不同router都得配置
經(jīng)過壓縮之后，third.js才80kb，app.js不到50kb，而且third.js一般是強緩存的，文件已經(jīng)很小了，沒必要做分屏加載
選擇靠譜的構建工具
在公司內(nèi)部做項目，當然盡量選用公司自己的框架，而百度的 fis3 那會兒已經(jīng)基本成熟了，有了400+的插件，支持我們當時的React重構是問題不大了。而且，當時已經(jīng)有人拿fis3做過構建React的重構，還分享了經(jīng)驗——如何用 fis3 來開發(fā) React?
fis3 是一個很不錯的構建工具，至少我們在使用過程中還比較滿意。除了基本功能，它的動態(tài)假數(shù)據(jù)模擬、發(fā)布到測試機這些功能非常實用，詳情請看官網(wǎng)文檔。但是它最大的問題是生態(tài)、圈子上還沒有webpack、gulp大，因此用的人少，用的人越少了生態(tài)就越小。
為項目選擇打包工具，除了基本功能（打包、壓縮、合并、編譯less等語法糖、生成md5后綴等等），以下幾點是最必須考慮的內(nèi)容。
編譯 React 的 .jsx格式和 ES6 語法
支持 npm 生態(tài)，支持js的模塊管理
動態(tài)引用css和圖片（因為要用組件化開發(fā)，組件需要的css要在組件中引用）
按需打包js
模擬假數(shù)據(jù)，運行代碼
支持多種編譯模式，例如dev模式下不壓縮代碼、方便調(diào)試，而publish模式下壓縮代碼、壓縮資源
下面挨著說明一下，以上幾點使用fis3時如何配置的，也權當幫助公司宣傳一下國產(chǎn)前端編譯神器——fis3
注意：以下所提到的fis3的配置，都要寫在./fis-conf.js代碼中，這是fis3的規(guī)則，可以去查閱官網(wǎng)的文檔。另外，以下代碼注釋中提示要npm install ... --save-dev安裝的插件，你都可以在 github.com 上找到。
編譯 React 的 .jsx格式和 ES6 語法
一般情況下，編譯ES6都用babel，編譯jsx也有相應的工具，但是沒成想這兩個只需要用typescript這一插件就搞定了。速度還要快，不過編譯打包，速度慢一點也沒關系，不考慮這個因素。但是使用typescript確實很方便。
支持 npm 生態(tài)，支持js的模塊管理
以下配置即可是的fis3支持npm生態(tài)，并且選擇使用commonjs的模塊化方案。這樣我們使用 npm install react --save 之后，在js代碼中，就直接可以使用import * as React from 'react'了，符合目前js的主流寫法。
動態(tài)引用css和圖片
前端現(xiàn)在都是組件化開發(fā)的思路，一個項目中可能需要很多css代碼，但是一個組件中，就只引用它自己需要的代碼，然后構建工具再將所有組件引用的css文件合并起來，一起給最終的頁面——這是組件化中使用css的思路。
使用以下配置，我們可以在js文件中直接引用css和圖片文件，跟webpack中使用相似。如果使用ES6語法，引用css時寫import './style.css'，引用圖片時寫 import * as url from '../img/abc.png'
按需打包js
因為是組件化開發(fā)，因此項目中所有的圖片都是零散的放在各個組件里面的，因此最終打包之后，要將所有的圖片都打包到一個統(tǒng)一的目錄下，方便管理
最終打包完成的時候，我們要將項目中用到的所有代碼都打包成以下幾個文件：
app.js 程序員手寫出來的業(yè)務代碼，后期的二次開發(fā)或者維護調(diào)整比較頻繁，單獨打包成一個文件；
third.js 第三方插件的代碼，例如 React Redux 等，后期幾乎不調(diào)整，單獨打包成一個文件，可直接使用http強緩存，提高性能；
aio.css 所有的css文件
lib.js 直接以<script>方式寫在html頁面上的幾個js文件，都打包成 lib.js ，減少http請求
具體配置查看如下代碼，注釋中寫的也非常清楚了
模擬假數(shù)據(jù)，運行代碼
大部分情況下，開發(fā)的代碼要查看效果都是啟用 fis3 server start 然后在本地瀏覽器打開 127.0.0.1:8080 來自測的，而此時本地是沒有服務器端的接口的，例如本地頁面中有一個/news?tn=gethotnews這個ajax請求（舉例用，實際上根本沒有 gethotnews 這個接口名稱），默認會請求127.0.0.1/news?tn=gethotnews，是會返回404的。那這時候怎么辦呢？
提前你要查閱fis3關于假數(shù)據(jù)模擬的 文檔說明
選擇一，你可以為/news?tn=gethotnews這個接口準備一個靜態(tài)的json文件，文檔中說過了。但是新聞webapp的接口實在是太多了，為每個接口都準備一下，耗費很多工作量，而且萬一接下來接口返回的數(shù)據(jù)結(jié)構有變化，還得跟著改，麻煩。因此我們選擇第二種。
選擇二，如果在本地訪問有/news?tn=gethotnews，通過借助fis3的一些功能，能直接返回線上m.news.baidu.com/news?tn=gethotnews的數(shù)據(jù)，這樣是不是就一步搞定了！下面說說該如何操作。
首先，新建一個./config/server.conf的文件，內(nèi)容如下。意思是，只要發(fā)出去的網(wǎng)絡請求的url符合^\/news.*$這個正則規(guī)則，就交給/test/data.js來處理，具體如何處理，往下看。
其次，新建一個./test/data.js的文件，內(nèi)容我就不能直接粘貼了，意思就是通過nodejs來抓取線上的結(jié)果。這樣就完成了動態(tài)獲取線上數(shù)據(jù)的功能。
此外，fis-conf.js中還需如下配置，意思是./test和./config兩個文件夾下的內(nèi)容，打包時候要按照既定的路徑打包。即 ./test/data.js這個路徑，打包之后還是./test/data.js這個路徑。
支持多種編譯模式
這個需求也是我們開發(fā)中必須的。例如，我們要為上線打包文件時，需要讓js有md5后綴（為了方便緩存），文件要壓縮到最��；而我們要自測打包的時候，就無需md5后綴（否則一天下來產(chǎn)生很多冗余文件），文件不要壓縮（否則無法在瀏覽器調(diào)試）。
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 生態(tài)
其實這里不應該是一個問題，不過當時有一個小小的糾結(jié)，就順便在這里記錄一下吧。
解決的問題
我們現(xiàn)在主流的開發(fā)方式，引用 React 一般都是 npm install react --save，然后在代碼中直接 import * as React from 'react'來引用。這就是所謂的“npm 生態(tài)”，即使用 npm 來管理依賴。
但是當時就這個用法，出現(xiàn)過一個糾結(jié)，即這樣依賴，我們打包的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生態(tài)，社區(qū)中的寫法基本已經(jīng)固定了，現(xiàn)在卻不這么寫，自己獨創(chuàng)一個寫法，那樣會越走越窄。哪怕會有那么一點的不完善，我也要按照大家通用的格式來，不要獨創(chuàng)。
其實后來想了一下，按照解決方案那種使用react.min.js的方式，也是有很多問題的。例如，開發(fā)模式下也用.min.js那樣就沒有React自帶的提示、警告功能了，萬一忽略了什么性能問題，沒有提示和警告，可就麻煩打了。再例如，這樣一來就沒有版本管理了，前端框架更新很快，版本管理很重要。
最后，我們發(fā)下經(jīng)過各種壓縮，最后的third.js都不到100kb，完全滿足我們的要求————這個年代，真的用不著自己去創(chuàng)新。
系統(tǒng)設計（邏輯）
要降低系統(tǒng)設計的復雜度，前端目前最好的方式就是組件化。將系統(tǒng)劃分成若干個頁面，然后將每個頁面都劃分成若干個組件，還要抽象出多個頁面中都會用到的通用組件，這是第一步。接下來要看組件和組件之間如何傳遞數(shù)據(jù)，即數(shù)據(jù)管理和狀態(tài)管理該如何做。下面我們就從這兩個方面來分先一下新聞webapp該如何設計。
從 router 到 page 再到 component
下圖是一個最基本的設計理念，實際項目中也是按照這個來細化、擴展最后落地執(zhí)行的。即，先給頁面劃分組件，然后組件構成頁面，最后頁面匹配路由。如下圖：
將這個落實到頁面上，就是這個效果
但是最后在開發(fā)過程中忽略了一個問題，就是一些復雜頁面（例如新聞NBA頻道頁，用瀏覽器模擬手機查看效果），光這種“頁面 - 組件”的形式是不夠的，應該在加一個subpage層，這樣就擴展性更好一些了。如下圖：
總結(jié)：一個項目總會遇到個別的比較復雜的頁面，因此這種page - subpage - component會更加合理一些，其中的subpage在不需要的時候省略掉就是了。
智能組件 VS 木偶組件
在 React + Redux 結(jié)合作為前端框架的時候，提出了一個將組件分為“智能”和“木偶”兩種
智能組件：它是數(shù)據(jù)的所有者，它擁有數(shù)據(jù)、且擁有操作數(shù)據(jù)的action，但是它不實現(xiàn)任何具體功能。它會將數(shù)據(jù)和操作action傳遞給子組件，讓子組件來完成UI或者功能。這就是智能組件，也就是項目中的各個頁面。
木偶組件：它就是一個工具，不擁有任何數(shù)據(jù)、及操作數(shù)據(jù)的action，給它什么數(shù)據(jù)它就顯示什么數(shù)據(jù)，給它什么方法，它就調(diào)用什么方法，比較傻。這就是木偶組件，即項目中的各個組件。
因此，數(shù)據(jù)在page層獲取、數(shù)據(jù)的操作和處理在page層定義，組件就是傻傻的知道執(zhí)行和顯示就行了，各操各的心。這種設計也整好符合目前無論是Vue、augular還是React提倡的基于數(shù)據(jù)驅(qū)動的設計理念——程序定義好Model和View的關系，剩下的業(yè)余處理只需要關心數(shù)據(jù)變化，View的變化由框架自動執(zhí)行，無需像jquery時代再去手動操作DOM。
數(shù)據(jù)管理
下面看一下數(shù)據(jù)在系統(tǒng)中是如何傳遞的。這里的數(shù)據(jù)分為兩種：
第一種可以稱之為“系統(tǒng)數(shù)據(jù)”，和業(yè)務無關的，一般任何系統(tǒng)中都會有。例如用戶id、用戶頭像、配置信息等，這個的特點就是符合單例模式，全局共用一套
第二種可以稱之為“業(yè)務數(shù)據(jù)”，每個頁面都可能不一樣。如在娛樂頻道需要的是娛樂新聞列表，而到了軍事頻道就需要軍事新聞的列表了，再到新聞詳情頁就需要新聞的內(nèi)容了
針對這兩種不同的數(shù)據(jù)，當然要分開處理。針對第一種“系統(tǒng)數(shù)據(jù)”，系統(tǒng)一初始化就立即獲取，然后交給Redux做管理，這也符合Redux的特點。而針對第二種“業(yè)務數(shù)據(jù)”，那就什么時候用，就什么時候獲取。
代碼架構（物理）
使用React + Redux設計代碼結(jié)構，目前方式都比較統(tǒng)一，基本都是按照以下方式來設計，這些在github等社區(qū)都能找到相似的結(jié)構。
以上目錄中，app/components和app/container是開發(fā)中修改最多的目錄。app/container里面定義的都是頁面，即智能組件，只關心數(shù)據(jù)，功能比較單一，因此結(jié)構也比較簡單
但是針對組件app/components來說，要顯示樣式，當然就需要css和圖片，文件類型比較多。因此，要按照如下方式定義組件
即，用一個文件夾來表示單個組件，里面的index.jsx是業(yè)務和模板代碼，style.less是樣式，img/文件夾放圖片文件。這樣的話，可以把每個組件都作為一個整體來管理，而且引用的時候也比較方便，例如import LoadMore from '../../app/components/LoadMore'就可以了——目錄名即組件的名字。
雖然我沒法將源碼的目錄結(jié)構截圖出來分享給大家，但是我們實際開發(fā)中的目錄結(jié)構基本是按照這個方式來做的，可能就是細節(jié)上因此會因為業(yè)務的問題做了特殊處理，但是設計理念上是一樣的。
開發(fā) - 如何多人協(xié)作開發(fā)
上文已經(jīng)描述了一些基本配置和系統(tǒng)設計的解決方案，接下來即可進入開發(fā)。由于不是一個人做，因此必須考慮如何高效率的多人協(xié)作開發(fā)。其實這不是一個技術問題，這里就簡單寫一下這方面的心得體會吧。
定義階段
提前定義好代碼結(jié)構，統(tǒng)一各個文件夾的作用
提前設計Router規(guī)則，以及和頁面的對應關系
提前抽象出可能在多個頁面中通用的組件，創(chuàng)建文件夾（占位置）
討論確定每個頁面都如何拆分組件，統(tǒng)一設計思路
開發(fā)階段
每人開發(fā)不同的頁面，遇到頁面單獨用的組件，即自行開發(fā)；
遇到多頁面公用的組件，先同步組內(nèi)開發(fā)進度，有則直接用，沒有則自己開發(fā)；
每裝配好一個組件，都提交一次代碼，隨時開發(fā)、隨時提交、隨時合并；
心得：如果你要參與一個重構項目，你只需要按部就班發(fā)揮自己的技術能力即可，按照規(guī)則編碼、測試、提交代碼等。但是如果你要自己組織、規(guī)劃一次系統(tǒng)重構，考慮的事情那就太多了。除了頂住外在的壓力之外，還得考慮如何讓這件事兒更快、更穩(wěn)定的運行起來。
開發(fā) - 自測
使用fis3作為構建工具，其實使用fis3 server start即可啟動本機的服務，然后進行測試。但是像新聞這種產(chǎn)品，它的任何頁面都需要獲取數(shù)據(jù)再展示，因此測試的時候需要一些模擬的或者真實的數(shù)據(jù)，這個fis3也支持，在上文介紹fis3配置的時候已經(jīng)說明了。
但是這種本機運行、并用fis3動態(tài)假數(shù)據(jù)模擬的情況有一個問題：它沒法模擬登錄的情況，http請求中也沒有登錄狀態(tài)下的那些cookies信息，這就會影響很多功能的測試。因為新聞的許多功能是需要登錄才能運行的，例如個人收藏、訂閱頻道、評論、點贊等。
最終想到的一個辦法是將代碼放在公司內(nèi)部的一臺測試機上，然后通過測試機訪問，這樣就可以獲取登錄信息。因此這里介紹一下如何使用fis3將代碼發(fā)布到測試機上。fis-conf.js中做如下配置：
配置完了之后，執(zhí)行fis3 release remote，它就會執(zhí)行編譯，并且將編譯后的文件傳上去。然后再在測試機上配置一個服務，支持頁面的訪問即可。
開發(fā) - 代碼檢查
代碼檢查是開發(fā)環(huán)境中非常重要的一步，其實這塊的配置很簡單，之所以單獨列出來，就是為了體現(xiàn)它在開發(fā)過程中（特別是多人協(xié)作）的重要性。
項目中使用eslint做檢查，其主要配置文件有兩個。.eslintignore定義了忽略哪些文件的檢查，例如我們要忽略一個第三方插件的代碼檢查
還有一個.eslintrc.json定義了代碼的檢查規(guī)則，本項目的檢查規(guī)則相對比較寬松，配置如下。其配置項的意義，在網(wǎng)絡上可以輕松查詢到。
最后，我們將檢查代碼的命令封裝進package.json中，如下代碼。這樣，在檢查的時候，只需要運行npm run lint這個簡單命令即可
目前只是軟性的規(guī)定，在git commit之前必須做檢查，如果開發(fā)人員忽略了，也能將代碼提交上。接下來將考慮將代碼檢查強制做到git-hook里面，即git commit之前必須要檢查通過，否則無法提交。
打包 & 提測
上文說過，自測的時候，發(fā)布的代碼是未經(jīng)過壓縮、也未加md5后綴的，而且直接將代碼發(fā)布到服務器的目錄即可，無需存到指定目錄。但是要打包出一個目錄，然后將文件提交給測試人員，就和自測不一樣了。
首先，打包的文件要壓縮、要加md5后綴（上文講述fis3的配置的時候已經(jīng)說過）；其次，要講文件打包到指定目錄，這里定義將文件打包到./release目錄下；第三，fis3的默認release功能還會將開發(fā)環(huán)境的源文件一起打包了，這些是不需要的（僅僅需要合并出來的代碼即可，合并的代碼在./release/static目錄下）。將以上這些需求一整合，寫一個復雜的命令一起放在package.json中
這樣，執(zhí)行npm run publish即可生成一個./release文件夾，里面包含了最終的模板文件、編譯之后的js和css、以及處理之后的圖片文件。目錄結(jié)構如下。最終，將這個文件夾提交給測試人員部署即可。每個公司都有自己的提測流程，百度內(nèi)部流程這里就不說了。
測試過程中，qa可能會有反饋bug，至于如何修復bug，以及如何進行二次開發(fā)和維護，我都寫了一個說明文檔（僅供百度內(nèi)網(wǎng)訪問），規(guī)定了每個步驟該如何執(zhí)行。
上線
測試完了之后要上線，每個公司的上線步驟也都不盡相同，有的高級一些，有的low一些，這里就不管了。
上線之后注意如何及時快速的回滾，這一點很重要。
總結(jié)
洋洋灑灑寫了好多，最后做一個簡單的總結(jié)。
系統(tǒng)重構的目的永遠都是為了后面減少開發(fā)成本、提高系統(tǒng)性能和穩(wěn)定性，這是公司或部門需要的結(jié)果。對于實際執(zhí)行的個人來說，參與或發(fā)起重構項目，是對自己如何掌控一個產(chǎn)品前端設計和架構的一次很好的機會，會對自己有很大的能力提升。重構過程中會遇到一些預想不到的問題，思考在過程中解決這些問題，對自己又是另一方面的能力提升。因此，好的東西，都是雙贏的。
待優(yōu)化
繼續(xù)壓榨性能：無論是通過資源的懶加載，還是使用Immutable.js做不可變數(shù)據(jù)，都要讓性能達到最優(yōu)
完善一些設計不足的地方：例如目前的page - components 改為到 page - subpage - components的方式
接下來
選擇React框架肯定要再試圖往兩個方向來攻：
服務器端渲染
React Native
最后
現(xiàn)在一言不合就秀配置打包代碼～
下載 
下載 
下載 
下載 
下載 
下載 
下載 
下載 
下載 
下載 
下載 
下載 
下載 
下載 
下載 
下載 
下載 
下載 
下載 
下載 
下載 
下載 
下載 
下載 
下載 
喜歡 
頂
難過
囧
圍觀
無聊
