動手實現 React-redux（六）：React-redux 總結

到這裏你們已經掌握了 React-redux 的基本用法和概念，而且本身動手實現了一個 React-redux，咱們回顧一下這幾節都幹了什麼事情。

React.js 除了狀態提高之外並無更好的辦法幫咱們解決組件之間共享狀態的問題，而使用 context 全局變量讓程序不可預測。經過 Redux 的章節，咱們知道 store 裏面的內容是不能夠隨意修改的，而是經過 dispatch 才能變動裏面的 state。因此咱們嘗試把 store 和 context 結合起來使用，能夠兼顧組件之間共享狀態問題和共享狀態可能被任意修改的問題。

第一個版本的 store 和 context 結合有諸多缺陷，有大量的重複邏輯和對 context 的依賴性過強。咱們嘗試經過構建一個高階組件 connect 函數的方式，把全部的重複邏輯和對 context 的依賴放在裏面 connect 函數裏面，而其餘組件保持 Pure（Dumb） 的狀態，讓 connect 跟 context 打交道，而後經過 props 把參數傳給普通的組件。

而每一個組件須要的數據和須要觸發的 action 都不同，因此調整 connect，讓它能夠接受兩個參數 mapStateToProps 和 mapDispatchToProps，分別用於告訴 connect這個組件須要什麼數據和須要觸發什麼 action。

最後爲了把全部關於 context 的代碼徹底從咱們業務邏輯裏面清除掉，咱們構建了一個 Provider 組件。Provider 做爲全部組件樹的根節點，外界能夠經過 props 給它提供 store，它會把 store 放到本身的 context 裏面，好讓子組件 connect 的時候都可以獲取到。

這幾節的成果就是 react-redux.js 這個文件裏面的兩個內容：connect 函數和 Provider 容器組件。這就是 React-redux 的基本內容，固然它是一個殘疾版本的 React-redux，不少地方須要完善。例如上幾節提到的性能問題，如今不相關的數據變化的時候其實全部組件都會從新渲染的，這個性能優化留給讀者作練習。

經過這種方式你們不單單知道了 React-redux 的基礎概念和用法，並且還知道這些概念究竟是解決什麼問題，爲何 React-redux 這麼奇怪，爲何要 connect，爲何要 mapStateToProps 和 mapDispatchToProps，什麼是 Provider，咱們經過解決一個個問題就知道它們到底爲何要這麼設計的了。

下一節：使用真正的 Redux 和 React-redux

上一節：動手實現 React-redux（五）：Provider