說一說 React 和 Redux 你知道或者不知道的一些事情

本文介紹一下本身在使用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。