動手實現 Redux（六）：Redux 總結

不知不覺地，到這裏你們不單單已經掌握了 Redux，並且還本身動手寫了一個 Redux。咱們從一個很是原始的代碼開始，不停地在發現問題、解決問題、優化代碼的過程當中進行推演，最後把 Redux 模式本身總結出來了。這就是所謂的 Redux 模式，咱們再來回顧一下這幾節咱們到底幹了什麼事情。

咱們從一個簡單的例子的代碼中發現了共享的狀態若是能夠被任意修改的話，那麼程序的行爲將很是不可預料，因此咱們提升了修改數據的門檻：你必須經過 dispatch執行某些容許的修改操做，並且必須大張旗鼓的在 action 裏面聲明。

這種模式挺好用的，咱們就把它抽象出來一個 createStore，它能夠產生 store，裏面包含 getState 和 dispatch 函數，方便咱們使用。

後來發現每次修改數據都須要手動從新渲染很是麻煩，咱們但願自動從新渲染視圖。因此後來加入了訂閱者模式，能夠經過 store.subscribe 訂閱數據修改事件，每次數據更新的時候自動從新渲染視圖。

接下來咱們發現了原來的「從新渲染視圖」有比較嚴重的性能問題，咱們引入了「共享結構的對象」來幫咱們解決問題，這樣就能夠在每一個渲染函數的開頭進行簡單的判斷避免沒有被修改過的數據從新渲染。

咱們優化了 stateChanger 爲 reducer，定義了 reducer 只能是純函數，功能就是負責初始 state，和根據 state 和 action 計算具備共享結構的新的 state。

createStore 如今能夠直接拿來用了，套路就是：

// 定一個 reducer
function reducer (state, action) {
  /* 初始化 state 和 switch case */
}

// 生成 store
const store = createStore(reducer)

// 監聽數據變化從新渲染頁面
store.subscribe(() => renderApp(store.getState()))

// 首次渲染頁面
renderApp(store.getState()) 

// 後面能夠隨意 dispatch 了，頁面自動更新
store.dispatch(...)

如今的代碼跟 React.js 一點關係都沒有，接下來咱們要把 React.js 和 Redux 結合起來，用 Redux 模式幫助管理 React.js 的應用狀態。

下一節：動手實現 React-redux（一）：初始化工程

上一節：動手實現 Redux（五）：不要問爲何的 reducer