虽然写了三年的 React，但是由于所负责项目规模都不是很大，一直未接触 Redux 进行 state 管理，近期新项目需要，所以根据官网系统的学习了 Redux。整理成文档，增加自己记忆。
动机
前端 SPA 越来越复杂，state 包括：服务器返回、本地产生、UI状态管理数据。这些数据互相影响，修改一个数据，可能引起其他并没有直接关联的UI更新。当业务很复杂，数据状态很多时候，普通的数据管理，开发者对数据管理失控，造成不必要的麻烦。所以需要引入一种数据管理机制，更好的对 state 进行管理。
核心概念
Redux 内置了发布订阅模块，组件之间数据交互不需要用 Props 一层层传递。应用的 state 统一放在 store 里面维护，当需要修改 state 的时候，dispatch 一个 action 给 reducer，reducer 算出新的 state 后，再将 state 发布给事先订阅的组件。
所有对状态的改变都需要 dispatch 一个 action，通过追踪 action，就能得出 state 的变化过程。整个数据流都是单向的，可检测的，可预测的。
State：用 object 表示，这个对象类似于一个 model，但是这个 model 没有 setter 方法，是未了防止不正确的暴力修改。
{
obj1: {
key1: 'val1',
key2: 'val2'
},
obj2: {
key3: 'val3'
}
}
Action: 如果我们想要改变 state，那么我们需要发布一个 action，这个action需要包含：type 和 data。
{ type: 'ADD', text: '111' },
{ type: 'DELETE', text: '222' }
Reducer: 一个函数，参数为 state 和 action，监听action的广播，通过 action 的 type 判断更新的饿类型，然后 action 的数据来更新 state，返回新的 state 最后由框架告知所有订阅这个 state 的组件，进行组件的更新。
function reducer1 (state={}, action) {
if (action.type === 'ADD') {
state.key2 = action.text;
} else {
return state;
}
}
以上为 Redux 的设计理念，将所有的state进行统一管理，使用者只要关心自己 view 是依赖哪个 state 字段，需要更新的时候，dispatch 一个 action， 然后 reducer 返回新的 state 就可以。
三个基本原则
- 单一数据源
所有的State都是存储于一个Store内。 这样做的原因：服务器端返回的数据可以直接传递给客户端，不需要编写额外的代码；单一 state 树使调试变得更加便捷。undo、 redo 等不好实现的方法，由于存于一个 state 树，可以马上实现了。
- State 是 只读的。
更改 state 只能通过发布 action （一个 object 描述这个更改的类型和需要的数据）。
无论 view 还是 server， 都无法直接更改 state， 只能通过 action 这个 object 来进行更改，由于 object 更利于记录、序列化、存储，所以对于调试和测试更加方便。
- Reducer 是 纯函数
接收 action， 如何转换 state 树，你需要编写纯函数。
Reducer 接收 action 和 前一个 action， 最后返回一个新的 state， 他是一个纯函数。记住，他是返回了一个新的 state， 而不是修改前一个state。 开发时，可以先编写一个简单的函数，然后后期进行扩充和优化，可以拆分，可以合并，可以公用。
总结
根据官网文档，简单的看了下Redux的核心概念和三个原则，对于Redux有了大致了解。后面继续学习：Redux简单使用、React-redux的实现原理、最新的context 和 redux 的对比。
