学习React有一段时间了，但对于Redux却不是那么理解。网上看了一些文章，现在把对Redux的理解总结如下
从需求出发，看看使用React需要什么
1. React有props和state
props => 父级分发下来的属性
state => 组件内部可以自行管理的状态
React有个特点就是，它没有数据向上回溯的能力，也就是说数据只能单向向下分发，或者自行内部消化
2. 构建的一个React组件内部可能是一个完整的应用, 它自己可以工作的很好。 但是你会发现React根本无法让两个组件互相交流，使用对方的数据. 这个时候如果不通过DOM沟通(也就是React体制内)， 解决的唯一办法就是提升state, 将state放到共有的父组件中来管理，再作为props分发回子组件.
3. 如果子组件需要改变父组件的state，也就是说，要从下往上改变state，有没有办法呢
唯一的办法，只能是通过onClick触发父组件声明好的回调，也就是说，父组件提前声明好函数或者方法作为契约描述自己的state将如何变化,再将它同样作为属性props交给子组件使用
这样就是一个模式, 数据总是单向从顶层向下分发，只有子组件回调在概念上可以回到state顶层影响数据，这样state在一定程度上是响应式的
4. 针对上面的情况和理解，最容易的开发方法，就是把所有的state集中放到所有组件顶层，然后分发给所有组件
5. 为了更好的管理所有的state, 我们可能就需要一个库来作为更专业的顶层state分发给所有的React应用, 这个就是Redux了。
根据上面的需求，我们结合Redux的三大要素来一起看看:
a. 需要回调通知state(等同于回调函数) => action
b. 需要根据回调处理(等同于父级方法) => reducer
c. 需要state(等同于总状态) => store
上面的action, reducer 和 store就是Redux的三大要素 (Redux三剑客： action, reducer, store)
a. action是纯声明式的数据结构，只提供事件的所有要素，不提供逻辑
b. reducer是一个匹配函数，action的发送是针对全局发送. 所有的reducer都可以捕捉到并匹配与自己相关与否。 相关就拿走action中的要素进行逻辑处理，修改store中的状态，不相关就不对state做处理原样返回.
c. store负责存储状态并可以被react api回调，发布action
当然一般不会直接把两个库拿来用，在React和Redux之间还有一个binding叫做react-redux, 提供一个Provider和connect :
a. Provider是一个普通组件，可以作为顶层app的分发点，它只需要store属性就可以了。 它会将state分发给所有被connect的组件，不管它在哪里，被嵌套多少层
b. connect是一个科里化函数， 意思是先接受两个参数(数据绑定mapStateToProps和事件绑定mapDispatchToProps), 再接受一个参数(将要绑定的组件本身)
mapStateToProps: 构建好Redux系统的时候，它会被自动初始化，但是你的React组件并不知道它的存在，因此你需要分拣出你需要的Redux状态，所以你需要绑定一个函数，它的参数是state，简单返回你关心的几个值
mapDispatchToProps: 声明好的action作为回调，也可以被注入到组件里，就是通过这个函数，它的参数是dispatch，通过redux的辅助方法bindActionCreator绑定所有action以及参数的dispatch，就可以作为属性在组件里面作为函数简单使用了，不需要手动dispatch。这个mapDispatchToProps是可选的，如果不传这个参数redux会简单把dispatch作为属性注入给组件，可以手动当做store.dispatch使用。这也是为什么要科里化的原因。
在这里，再次理解单向数据流，就是当用户进行操作的时候，会从组件发出一个action, 这个action流到store里面，触发store对存储在store里面的状态进行改动，然后store又触发组件基于新的状态来重新渲染.
这样的话，通过这个流程，任何状态的变化都必须通过action触发，而action又必须通过dispatcher（调度）走，所以整个应用的每一次状态变化都会从同一个地方流过.
React中一直强调的一点就是 "理解你的应用的状态变化是很困难的(managing state changing over time is hard)", 通过redux, 可以让所有的状态变化都必须留下一笔记录，这样就可以利用这个来做各种debug工具，历史回滚等.