說一說 React 和 Redux 你知道或者不知道的一些事情
本文介紹一下自己在使用React和Redux過程中的一些思考，主要面向初學者。
1. 為什么要有redux
傳統前端開發中，把模板和功能邏輯分開作為一種最佳實踐，React采用了不同的思路，通過組件把模板和邏輯組合在一起。但是React也并不是一個完整的組件化框架，其組件化只是主要集中在展示層面，如果要構建復雜的應用，在React component中放置太多的邏輯代碼，不僅組件化的初衷復用性會降低，從代碼維護的角度看也不合理。
Flux是非死book提出的一種前端架構模式，通過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反而是一種最簡便快捷的方式。
組件拆分的博弈
組件拆分并不是顆粒越小越好，找到一個可以被復用的平衡點即可，拆分過細反而增加了代碼的復雜度。
最后
非死book最近開源了litho，其設計思路與react如出一轍。對于Android開發者來說，也是一個顛覆性的創新。同時litho提到的異步布局、View復用對于開發者來說也具有很大的吸引力。
為了督促自己更新博客，先在這里立個flag。
來自：https://juejin.im/post/590fb6fea0bb9f00589d7667