摘要：將它開源出來，希望能給某些同學帶來幫助，如果有設計的不好的地方，也希望能及時指出，共同進步。和為組件，下的文件一般為直接配合路由使用的包裝組件，為具體業(yè)務組件，這個地方有的規(guī)范將組件分為三層，我個人認為這個必要性不大。

個人學習使用react已經(jīng)有一段時間了，雖然沒有在真正的產(chǎn)品項目中大規(guī)模使用react，但是在自己的博客、小網(wǎng)站、一些開源項目中已經(jīng)使用過好幾次了，使用react創(chuàng)建項目個人也有了一些心得并且經(jīng)過嘗試驗證，總結(jié)了這個可以用于起步的框架模版react-redux-tpl。

將它開源出來，希望能給某些同學帶來幫助，如果有設計的不好的地方，也希望能及時指出，共同進步。

在現(xiàn)在，我們其實有很多腳手架可以使用，例如create-react-app就是業(yè)界比較優(yōu)秀的應用開發(fā)工具之一，筆者也使用過，但是我的感覺是由于它已經(jīng)將所有的工具集成好了，可控性反而不那么強，有些內(nèi)容也不一定會了解的很透徹，但是自己從0開始配置呢，又會比較麻煩，每次從新開一個項目又需要做很多前置工作，比較麻煩。

react-redux-tpl這個模版就是為了解決這個問題，它基于Express，集成了ES6、react、redux(以及redux-dev-tool)、react-router、webpack熱更新，并且按照一定的規(guī)則和最佳實踐進行文件組織和代碼組織，可以使開發(fā)人員幾乎無需寫一行配置代碼就可以直接開發(fā)業(yè)務。

現(xiàn)在它的使用方式是這樣的：

npm install react-redux-tpl -g
react-redux-tpl FileName
cd FileName
npm install
npm run start

之后再chrome中打開localhost:7777即可看到效果(注：如果網(wǎng)速較慢，特別是在使用教育網(wǎng)的情況下，執(zhí)行第二個命令之后可能要稍微等幾分鐘)。

或者你也可以直接git clone https://github.com/aircloud/react-redux-tpl將整個模版項目下載下來，到這個文件夾里：

npm install
npm run start

同樣可以達到效果

我認為，一個一百個文件以上的項目，最重要的事情就是文件組織，文件組織對開發(fā)效率、維護效率、多人協(xié)作甚至代碼重用，都有很重要的意義，而現(xiàn)在隨著組件化開發(fā)的流行和更精確的粒度控制，我們的文件很容易變得非常多。

我在文件組織方式是這樣的，這里面主要列出重點目錄并著重突出一下前端文件:

-bin
-common //react核心文件目錄
 |- actions
 |- components
     |- Common
     |- HomePage
     |- SubPage
     ......
 |- containers
 |- enter
 |- reducers
 |- routes
 |- store
 |- Utils
-controller
-public //靜態(tài)資源目錄
 |- images
 |- javascripts
 index.html
-routes
-views
app.js
webpack.config.js
...... 

這里面首先說一下目錄命名規(guī)則，目錄出了最末端只有jsx的文件目錄采用大駝峰命名規(guī)則，并且和里面的首要jsx文件同名之外，一律采用小寫，并且盡量控制不出現(xiàn)復合單詞。

react核心文件目錄之所以命名common，是因為考慮到如果使用服務端渲染，這便相當于一個公共資源目錄，服務端渲染我們可以考慮在routes目錄下的路由層進行配置(該模版框架沒有采用服務端渲染，需要自行配置，但比較簡單)。

common下的actions、reducers、store都是和redux有關的文件目錄，enter為入口目錄，enter目錄下的文件通常為webpack配置時候的入口文件。

containers和components為組件，containers下的文件一般為直接配合路由使用的包裝組件，components為具體業(yè)務組件，這個地方有的規(guī)范將組件分為三層，我個人認為這個必要性不大。

另外，除了一些公共樣式需要放在公共文件，我建議每一個組件搭配一個同名樣式文件:

-HomePage.js
-HomePage.less

這樣控制起來會比較方便，另外我們可以嘗試采用css-modules，個人認為雖然解決了class沖突問題，但是卻不利于代碼調(diào)試，而且也有一定遷移成本，故不用。

關于webpack配置優(yōu)化的問題，網(wǎng)上的教程和博客都非常的多，我在react-redux-tpl進行了一部分優(yōu)化配置，并且利用了express的插件進行了熱更新的配置?？紤]到模版框架的通用和簡潔性，并且考慮到編譯速度優(yōu)化的選擇多樣性，我在這里簡化了配置。

如果對編譯時間要求比較高的話，僅僅做這些是不管用的，我們應當進行更多的性能優(yōu)化。關于webpack性能調(diào)優(yōu)，我在這里總結(jié)了一些內(nèi)容，可以進行嘗試。

另外這里面值得一提的是使用的webpack-hash-sync這個插件，關于引用的js文件名同步的問題，雖然已經(jīng)有html-webpack-plugin這個插件，但是我認為它是不符合我的編程習慣的，它是通過我們的配置，直接生成html文件，而實際上我們的html文件都是通常先寫好，并且做很多個性化配置內(nèi)容，方便又簡潔，直接使用html-webpack-plugin很多時候是無法做到的。

而使用webpack-hash-sync我們可以給定正則表達式，每次webpack的時候都會一個一個的去匹配正則表達式并且把hash值或者chunkhash進行改變：

new WebpackHashSync({
            file:["output.*?js","common.*?js"],
            path:path.join(__dirname, "public/"),
            html:["index.html"],
            hash:true,
            chunkhash:false
}),

項目中引入了redux-devtools這個調(diào)試功能插件(可關閉，最簡單的辦法就是不在common/enter/index.js中引入了)，并且默認引入redux-thunk和react-router-redux這兩個中間件，前者是可以直接在action中發(fā)異步請求，后者是可以增強一些react-router的功能。

我建議大家可以看看他們的GitHub主頁，講的都挺不錯的，特別是前者，十來行代碼的一個插件，近5000個star，不得不說，是牛逼。

在common/actions/index.action.js里，我寫了一些示例的同步的和異步的action，大家可以參考這個寫法，直接上手。

另外，我關于一個redux的使用原則是：

只有被共享數(shù)據(jù)才會被用在redux中，組件的非共享數(shù)據(jù)(比如一些展示列表)，不要放在redux中，而是隨著組件生命周期被請求、構(gòu)造、消失...

寫react的項目，最重要最耗時的，還是react組件開發(fā)，我關于組件粒度劃分的幾個原則如下(當然這在這個模版框架中可能沒有體現(xiàn)出來)：

如果列表中的元素存在動態(tài)交互，便盡可能地將元素做成一個獨立的組件。

為了提高效率和保持整站用戶體驗的統(tǒng)一，我們盡可能復用低級組件，比如定制的按鈕、列表、標簽等，并且都統(tǒng)一放在Common文件夾下。

在react組件開發(fā)中，我一般是給每一個模塊(或者一個頁面)一個文件夾，比如HomePage，這個文件夾下只有HomePage.js是需要被別的目錄下文件引入的，而HomePage需要的一些公共組件在Common目錄下，私有組件在HomePage本文件目錄下。

另外，我們可以在HomePage.js中利用ES7中的裝飾者模式配置react-redux：

@connect(state => {
    return {
        Info:state.rootReducer.getInfo.info
    };
}, {
    getAllClass,updateInfo
})
class HomePage extends Component{
 //...
}

其他的子組件的數(shù)據(jù)通過props傳入(當然，如果是子組件的私有數(shù)據(jù)，還是在子組件內(nèi)自行處理)

以上是我梳理的關于構(gòu)建這個模版框架的一些思考，由于某些內(nèi)容還未深思熟慮，因此目前沒有寫入，我也會在接下來的一段時間內(nèi)，繼續(xù)打磨這個內(nèi)容，爭取整理出一套還不錯的實踐。

如果有些許認同，歡迎給star鼓勵。

如果有bug或者設計不好的地方，請在這里提出，我會在24小時之內(nèi)回復并且嘗試解決問題。

[注1]本文中提到的一些對比的例子，都是個人角度的一些片面見解和個人習慣問題，實際上我個人還是認為這些項目十分優(yōu)秀的，成熟度也比較高，向前輩致敬。