pur*_*ulu 11 flux vue.js vuex es6-class
我一直在使用 Vuex，它坚持只通过它改变状态，mutators或者actions让我认为你的商店应该只包含尽可能平坦的对象，只有原始类型。
一些线程甚至规定规范化您的数据（因此，不是嵌套对象树，而是具有带有 id 数组的对象来指示树关系）。这可能与您的 JSON api 非常匹配。
这让我认为在您的通量存储中存储类（可能有改变自己的方法）是一种反模式。事实上，即使将您商店的数据混合到一个类中，似乎您也在逆潮流而动，除非您的类不对它的内部数据进行任何修改。
这让我想到，在 Vue/Vuex/Reactive/Flux 中使用任何类是一种反模式吗？
这些库似乎明确设计为与普通 JS 对象一起使用，并且您与 API 的一般交互（数据输入、数据输出）让我觉得更实用的方法（无不变性）是原始设计者所考虑的。
编写从function => test => state mutator wrapper around function.
我知道 JS 对象和 JS 类的行为非常相似（并且基本上是同一件事），但我的逻辑是，如果您不考虑类进行设计，那么您更有可能不会用非通量污染您的状态状态变化。
社区中是否普遍认为您的通量代码应该更实用，更少面向对象？
是的。你的想法是绝对正确的。像Redux,这样的状态容器Vuex应该保存您的数据结构而不是函数。确实，JavaScript 中的函数只是可调用的对象。您也可以在函数上存储静态数据。但这仍然不符合纯数据的条件。也是出于同样的原因，我们没有放入Symbols我们的状态容器。
回到 ES 类，只要您将类用作 POJO，即仅用于存储数据，那么您就可以自由使用它们。但是，如果您可以拥有简单的普通对象，为什么还要拥有类。
将数据与 UI 组件分离并将其移动到状态容器中是函数式编程的基础。大多数严格的函数式语言，如 Haskell、Elm、OCaml 甚至 Elixir/Erlang 都是这样工作的。这为您的应用程序中的数据流提供了强有力的推理。此外，在这些语言中，数据是不可变的。并且，因此没有像构造这样的有状态类的地方。
对于 JavaScript，由于事物本质上是可变的，因此边界有点模糊，很难定义好的实践。
最后，作为一个社区，对于使用函数式方式还没有明确的共识，但社区似乎正在朝着功能性更强、无状态的组件方法迈进。一些很好的例子是：
现在，即使我们在Vue和 中都有功能组件React。