vue中状态管理器的工作流程

vue中状态管理器的工作流程

最近用vue写了状态管理器，感觉里面的逻辑比较复杂吧，今天我先整理了一下vue中API和自己的理解总结了一下，没有代码光理解

vue API中的解释
state
Vuex 使用单一状态树——是的，用一个对象就包含了全部的应用层级状态。至此它便作为一个“唯一数据源 (SSOT)”而存在。这也意味着，每个应用将仅仅包含一个 store 实例。单一状态树让我们能够直接地定位任一特定的状态片段，在调试的过程中也能轻易地取得整个当前应用状态的快照。
单状态树和模块化并不冲突——在后面的章节里我们会讨论如何将状态和状态变更事件分布到各个子模块中。

Getter
如果有多个组件需要用到此属性，我们要么复制这个函数，或者抽取到一个共享函数然后在多处导入它——无论哪种方式都不是很理想。
Vuex 允许我们在 store 中定义“getter”（可以认为是 store 的计算属性）。就像计算属性一样，getter 的返回值会根据它的依赖被缓存起来，且只有当它的依赖值发生了改变才会被重新计算。

Mutation
更改 Vuex 的 store 中的状态的唯一方法是提交 mutation。Vuex 中的 mutation 非常类似于事件：每个 mutation 都有一个字符串的 事件类型 (type) 和 一个 回调函数 (handler)。这个回调函数就是我们实际进行状态更改的地方，并且它会接受 state 作为第一个参数。

Action
Action 类似于 mutation，不同在于：
Action 提交的是 mutation，而不是直接变更状态。
Action 可以包含任意异步操作。
Action 函数接受一个与 store 实例具有相同方法和属性的 context 对象，因此你可以调用 context.commit 提交一个 mutation，或者通过 context.state 和 context.getters 来获取 state 和 getters。当我们在之后介绍到 Modules 时，你就知道 context 对象为什么不是 store 实例本身了。

Module
由于使用单一状态树，应用的所有状态会集中到一个比较大的对象。当应用变得非常复杂时，store 对象就有可能变得相当臃肿。
为了解决以上问题，Vuex 允许我们将 store 分割成模块（module）。每个模块拥有自己的 state、mutation、action、getter、甚至是嵌套子模块——从上至下进行同样方式的分割。

自己的一些理解和总结吧
想必大家已经被api中解释搞得半懂不懂吧，接下来我通过图片，加上一些自己对状态管理器的理解总结一下。
从上图可以开始状态管理器就是把vue编程中的对数据操作和异步操作分离出去，从而更好地能改变，和维护程序。
然后是我的一些应用的理解总结：
1.先是在你的组件的store.js中，也就是处理状态的文件夹中，放入state，state其实就是组件的初始数据。
2.getters 状态管理器里的计算属性，因为有很多的复杂的计算应用，一有复杂的计算应用，就需要应用到计算属性，但是状态管理器store.js中没有计算属性，于是就在这里加入了getters，方便处理数据。
3.actions 在这里是进行接收数据，对数据进行操作，并在getters和接收到处理完的数据，通过commit，将数据传送到下一个属性mutations中的属性名中。
4.mutations 在mutations中是状态管理器中唯一能改变数据的地方，把action中处理完的数据，在mutations中，改变数据。它是唯一能触摸到vue中的虚拟dom状态的地方。(虚拟dom是什么，可以自己去了解)
5. 组件内的状态管理器就算设置好了，然后外面根项目中的总store.js管理器当中引入模块化管理，先是import引入要引进的组件中store.js,在export中引出模块，这样就可以方便管理和维护。
6. 最后就得去组件内部中引入vuex，在组件中用钩子函数得到$store的状态，用dispatch触发Action的状态，让Action里的动作能够运行，从而改变了值，得到了新的数据。然后利用组件中的计算属性，得到改变的值，再利用计算属性的原理，从来改变文档渲染的效果。