动手实现 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