有太多人不知道为什么要使用vuex，而使用它的目的还停留在“这是一个新技术，大家都在用，所以我也要用”

vuex并不难编写，但用好却不容易，“过度封装”“过早优化”十分常见。

如果你不知道为什么要使用它，那一定做不到用好它。所以这篇文章将解析vuex的优缺点，让你知道在什么情况下应该使用它，否则不该使用。

先提出观点: 能放在组件中的状态就不要放在state里，state只保存全局数据

任何东西有好也有坏，当好处大于坏处的场景下我们才应该使用它，vuex也是如此。

所以在使用它之前 必须明了它潜在的缺点

缺点

• 代码会更加复杂，原本只需要写在一个组件里的代码，现在需要写在多个地方(store中申明并定义好action等，组件中引入store去使用)，这也抛弃了单文件组件的优势。
• 当组件使用了store中的数据，就意味着这个组件将不再是一个“无副作用”的组件，那么这个组件的可重用性将大打折扣。
• Store只不过是一种全局变量，从一开始学习代码的时候有人就告诉我们: 不要去声明和操作全局变量，这将导致状态错综复杂让人头疼。
• Vue组件的父子组件通讯机制(emit和props)很好, 能够完美的解耦各个组件, 请一定要优先使用这种通讯方式.

为了避免诸多缺点 在使用Vuex之前有必要思考一下几点:

1. 使用vuex是否会引入垃圾变量

Store不会像组件一样有生命周期, 那么放在Store的状态(State)如果管理不好就会变成垃圾变量, 这也是能不能将变量放在Store中的重要判断条件.

所以记得不再使用的State记得销毁.

虽然JS也有GC, 但是和其他语言一样的, GC是有代价的, 如果能一个变量能简单的被销毁就应该及时销毁它, 正如Vue组件Destory机制存在的意义.

但其实, Store中没有生命周期机制 也没有提供给用户简单的销毁状态的机制, 所以只能通过 a = null 这样的写法, 这样的写法是低效的, 所以如果当一个变量应该频繁的被创建/销毁时, 它就不应该放在Store里.

2. 使用vuex会不会造成数据流错乱

单向数据流这个理念在引入Vuex之后可能会被开发者打乱. 但单向数据流无疑是应该遵守的.

Store既然是全局的, 那总会有人为了方便 在本来应该在子组件emit事件让父组件去请求api的场景下, 子组件直接使用vuex的action去操作了api.

这样的坏处不然而喻:

• 子组件无法解耦.
• 数据流错乱, 违背了单向数据库原则
• 多个地方都使用了vuex中的全局方法或状态，不易重构.

我举的例子只是其一, 以"悲观"的心态来猜测开发者写出的代码, 最后的错乱程度可能是无法想象的.

Store本身没有错, 但如果开发者用不好, 那就不要使用.

如何正确的使用Vuex

说了怎么多, vuex到底应该如何正确的打开?

笔者有几个准则

少用vuex

最好的避免坏处的方式就是不用.

人无完人, 谁也不能确定自己写出的代码是完美的, 说不定自以为完美的代码对于其他人来说就是乐色, 为了净化开发环境, 写越简单的代码被人吐槽的概率越小. 当然也是因为上帝喜欢简单 - 奥卡姆剃刀定律

在项目中，vue提供的props, on和emit已经能满足90%的数据传递需求，这种传递方式是“无副作用”的, 应当优先使用.

以"全局状态"的概念来小心看待vuex

牢记全局状态的副作用, 只有在对比了各种实现方式后, 发现vuex还是最优解时才使用它.

最后

我的观点可能会有些许偏激或者是不正确, 希望能在下方评论区得到你的建议.