本文介紹一下自己在使用React和Redux過程中的一些思考，主要面向初學者。
1. 為什麼要有redux
傳統前端開發中，把模板和功能邏輯分開作為一種最佳實踐，React採用了不同的思路，通過元件把模板和邏輯組合在一起。但是React也並不是一個完整的元件化框架，其元件化只是主要集中在展示層面，如果要構建複雜的應用，在React component中放置太多的邏輯程式碼，不僅元件化的初衷複用性會降低，從程式碼維護的角度看也不合理。
Flux是Facebook提出的一種前端架構模式，通過Flux的資料流模型可以非常優雅地處理應用中的資料流動，配合其他中介軟體使用可以處理複雜應用中的邏輯行為，從而提高程式碼的複用性和維護性。其中Redux是所有Flux具體實現中的一個佼佼者。
2. react redux工程化
這裡說一下在react、redux開發中可能會用到的一些方便開發的工具和值得研究的第三方庫。
react-redux
react-redux通過Provider和connect兩個介面簡化了react component與redux的繫結，幾乎是必用的一個庫。
redux devtools
可以使用chrome的Redux DevTools外掛，redux devtools功能非常強大，可以檢視store state和action的內容，而且是可以檢視所有階段的store中的資料，甚至撤銷或者重新執行action，站在絕對的上帝視角，可以幫助我們快速定位邏輯上的問題。
react-addons-perf
react-addons-perf是一個效能分析工具，可以列印react component的渲染時間，還可以分析元件渲染過程中浪費的時間，即執行了render方法，而沒有在dom上更新的地方，從而發現component中可以優化的環節。
react-addons-update
react-addons-update可以方便地建立不可變資料。我們知道為了效能優化中會使用shouldComponentUpdate方法來避免render無意義呼叫，但是shouldComponentUpdate本身的執行也不能過於複雜，否則反而是增加了執行時間，所以shouldComponentUpdate在對比oldprops和nextprops時一般使用淺對比（shallow compare）。這時如果是對可變物件進行淺比較，結果自然是不準確的，因此需要使用不可變物件，react-addons-update正可以滿足這種需求。
redux-logger
可以在console中輸出每一個action dispatch後state的變化，是程式碼除錯的好幫手。
redux-saga
通過使用generator可以優雅地處理非同步過程，並且可測試性強。
3. react效能優化的建議
網上已經有很多react效能優化的文章，個人覺得效能優化本身是一個博弈的過程，在程式碼可讀性、維護性與執行效能之間的博弈，很多時候效能優化犧牲了程式碼的可讀性，因此要在合適的時間，在需求基本完成時再進行優化，並且優化中要著眼於效能的瓶頸，沒有必要深挖每一個細節，破壞程式碼本身可讀性。
4. React使用中的一些博弈
其實React的出現本身就一個博弈的結果，模板和邏輯的分離還是組合的一個博弈結果，React採用元件的方式把傳統開發中的模板和邏輯放置在了一起。在選用React之前需要考慮下是否適合採用React。
shouldComponentUpdate
shouldComponentUpdate的加入是為了避免render方法的無效重複執行，但是如果shouldComponentUpdate函式本身會執行比較複雜的對比，那麼加入shouldComponentUpdate得不償失.
redux 博弈
在react中加入redux之後，會盡量設計”純”component （即對於傳入一定 props一定可以輸出確定的結果），元件間、甚至元件內部的狀態變化都要通過action來實現。但有時使用元件內部的state反而是一種最簡便快捷的方式。
元件拆分的博弈
元件拆分並不是顆粒越小越好，找到一個可以被複用的平衡點即可，拆分過細反而增加了程式碼的複雜度。
最後
Facebook最近開源了litho，其設計思路與react如出一轍。對於Android開發者來說，也是一個顛覆性的創新。同時litho提到的非同步佈局、View複用對於開發者來說也具有很大的吸引力。
為了督促自己更新部落格，先在這裡立個flag。