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