我一直在使用Vuex，它坚持只通过mutators或actions来改变状态，这使我认为您的商店应该只包含尽可能平坦的对象，并且仅包含基本类型
某些线程甚至规定了规范化数据的功能（因此，不是嵌套的对象树，而是带有ID数组的对象来表示树的关系）。这可能与您的JSON API非常匹配。
这使我认为将类（可能具有改变自身的方法）存储在通量存储中是一种反模式。的确，除非将类的内部数据不做任何修改，甚至将商店的数据合并到一个类中也似乎在逆流而上。
然后让我想到的是，在Vue / Vuex / Reactive / Flux中使用 any 类是反模式吗？
这些库似乎已明确设计用于普通的JS对象，并且与API的常规交互（数据输入，数据输出）使我觉得原始设计人员正在考虑使用一种更具功能性的方法（无不变性）
编写从function => test => state mutator wrapper around function开始的代码似乎也更容易。
我知道JS对象和JS类的行为非常相似（并且基本上是同一件事），但是我的逻辑是如果您在设计时不考虑类，那么您会可能不会因非通配状态更改而污染您的状态。
社区是否普遍同意您的流量代码应具有更多的功能并且应减少面向对象的使用？
答案 0 :(得分：0)
是的。您的想法绝对正确。像Redux，Vuex这样的状态容器应该保存数据结构而不是函数。确实，JavaScript中的函数只是可调用的对象。您也可以在函数上存储静态数据。但这仍然不符合纯数据的标准。出于同样的原因，我们也没有将Symbols放入状态容器中。
回到ES类，只要您将类用作POJO，即仅存储数据，就可以自由使用它们。但是，如果可以有简单的普通对象，为什么要有类。
从UI组件中分离数据并将其移到状态容器中是函数式编程的基本根源。大多数严格的功能语言（例如Haskell，Elm，OCaml甚至Elixir / Erlang）都以这种方式工作。这为您在应用程序中的数据流提供了强有力的推理。另外，在这些语言中，数据是不可变的，这一事实得到了补充。而且，因此没有像构造这样的有状态类的地方。
使用JavaScript时，由于事物本质上是易变的，因此边界有些模糊，很难定义良好的做法。
最后，作为一个社区，关于使用功能性方法尚无明确的共识，但似乎社区正朝着更具功能性，无状态的组件方法发展。一些很好的例子是：
现在，即使我们在Vue和React中都具有功能组件。