随着 JavaScript 单页应用开发日趋复杂，JavaScript 需要管理比任何时候都要多的 state （状态）。 这些 state 可能包括服务器响应、缓存数据、本地生成尚未持久化到服务器的数据，也包括UI状态，如激活的路由，被选中的标签，是否显示加载动效或者分页器等等。
管理不断变化的 state 非常困难。如果一个 model 的变化会引起另一个 model 变化，那么当 view 变化时，就可能引起对应 model 以及另一个 model 的变化，依次地，可能会引起另一个 view 的变化。直至你搞不清楚到底发生了什么。state 在什么时候，由于什么原因，如何变化已然不受控制。当系统变得错综复杂的时候，想重现问题或者添加新功能就会变得举步维艰。
这里的复杂性很大程度上来自于：我们总是将两个难以理清的概念混淆在一起：变化和异步。如果把二者分开，能做的很好，但混到一起，就变得一团糟。一些库如 React 试图在视图层禁止异步和直接操作 DOM 来解决这个问题。美中不足的是，React 依旧把处理 state 中数据的问题留给了你。Redux 就是为了帮你解决这个问题。
Redux 本身很简单。
本文章以官方文档为基础进行扩展,0基础 的朋友门推荐先看下官方文档-->[传送门]
Reducers 指定了应用状态的变化如何响应 actions 并发送到 store 的，记住 actions 只是描述了有事情发生了这一事实，并没有描述应用如何更新 state。
Store 就是把它们联系到一起的对象。Store 有以下职责：
维持应用的 state；
提供 getState() 方法获取 state；
提供 dispatch(action) 方法更新 state；
通过 subscribe(listener) 注册监听器;
通过 subscribe(listener) 返回的函数注销监听器。
Redux 应用只有一个单一的 store。当需要拆分数据处理逻辑时，你应该使用 reducer 组合 而不是创建多个 store。
简单来说：我们的action是把我们的数据提交上去的,那么提交到哪里呢?提交到我们的store内而我们的Reducers提交的就是对我们的数据变化所做出的操作，他们的桥梁就是我们的store.js文件
且我们的Action和reducers内都有两个js文件
个人认为reducers的main.js和actions的actionTypes.js作用不大。其实没必要把所有的东西都分的十分清楚。
(当然我认为分的清楚是很好，但是这感觉不就和层级性的循环地狱雷同了么.简单来说新手上手会很蒙)
所有我认为:分成五个种类就正好--例：(数据,派生数据,方法(不能直接修改state),过滤方法并修改(可以修改state),模块化)
下面是个人的简化写法
不多说先上图图片内的具体流程
1：dom树结点触发事件，例：onClick{()=>this.changeTab(item)}
2：事件内this.props.dispatch(changeTab_tab({avtiveKey:item.key})
dispatch连接的changeTab_tab是在actions下的tabActions定义并且引用的方法以便被触发
3：tabAction内通过return 返回type(和后面的switch-case要匹掉上)
4：reducers内的tabreducers-->内部用switch判断并且触发我们的case事件,返回相应结果 并export(曝光)
1：dom树结点触发事件，例：onClick{()=>this.changeTab(item)}
2：事件内this.props.dispatch(changeTab_tab({avtiveKey:item.key})
dispatch连接的changeTab_tab是在actions下的tabActions定义并且引用的方法以便被触发
3：tabAction内通过return 返回type(和后面的switch-case要匹掉上)
4：reducers内的tabreducers-->内部用switch判断并且触发我们的case事件,返回相应结果 并export(曝光)
