在redux中有OOP的位置吗？

我已经使用面向对象编程实践25年了，在过去的5年里，我一直在尝试函数式编程，但当我尝试做一些复杂的事情时，我的思维总是倾向于OOP，尤其是现在ES6支持良好的OOP语法，这是我构建东西的自然方式

我现在正在学习Redux，并且我理解（c.f.）将类实例放在约简器中是不允许的；而计算普通减速器顶部状态的推荐方法是使用选择器（例如，通过重新选择）。当然，React建议组合优先于继承（，）

但是，在React/Redux生态系统中，是否有任何地方可以容纳具有方法和继承的类对象

我想，为了回答我自己的问题，OOP类鼓励在同一位置添加数据属性和数据操作，这有利于可读性，但不适合纯函数和不可变数据

如果我要使用OOP，我是否需要放弃让我的实例在任何时间内保持并维护状态的想法？比如，每次我想使用一个，我都会从存储数据中实例化它，使用我想要的任何方法，然后扔掉它？这可能会消除很多使用OOP类的动力。但是如果我保留实例，我会很头疼保持它们与商店的同步

那么，当我尝试使用方法时总是使用选择器，当我尝试使用继承时总是使用组合，这是答案吗？具体地说，我指的是在存储和操作Redux存储中保存的数据以便在React组件中使用时。如果是的话，它应该放在哪里？连接到选择器？就像我建议的那样

---

为了清晰起见，添加我的用例：我的数据基本上是一个巨大的图形：许多对象具有许多属性，并且对象之间存在许多关系。它是只读的，但很复杂。我的对象称为“概念”

在做出迁移到Redux的决定（可能很愚蠢）之前，我使用类来构造和表示概念、概念集以及概念之间的关系。我的类包括用于获取概念集的异步api逻辑、关于每个概念的信息以及关于每个概念相关的其他概念的信息。如果用户选择向下钻取，这些类将递归地获取并实例化新的概念集。Redux文档建议对嵌套数据（）使用扁平的、规范化的结构，这对于存储来说可能是明智的，但我的OOP模型非常适合遍历图形和内容的各个部分。我很难使用选择器和不可变状态，这可能涉及嵌套，可能是循环，或者需要对更多数据进行异步调用

我正在成功地使用api的东西

---

也许@Sulthan的答案是正确的：我应该在我的Redux应用程序中自由使用OOP技术。但这看起来还是很奇怪。我无法保留我的对象，因为如果存储发生更改（例如，获取更多数据），我的对象可能会过时。如果我的对象是嵌套的，但我的存储是规范化的，我会在需要时（从选择器）实例化它们，并确保不将它们保留在周围

这个问题有点基于观点，但让我们集中讨论核心问题

函数式编程和面向对象编程之间没有矛盾。您只需要使用相同的编程模式。在函数式编程中使用类（带继承）是没有问题的，只要保持它们不变

为了证明我的观点，许多人用来在redux中保存状态的流行库是由类组成的。这些类具有继承性（例如，

OrderedSet扩展集

）

还要注意，大多数

React

组件都是类，它们也使用继承（

…扩展React.Component

）。

答案是，这是可能的，但非常不鼓励使用继承，而且不惯用

React确实依赖类和

React.Component

的单级继承来实现具有生命周期的有状态组件，但是官方不鼓励您在组件中执行进一步的继承级别

Redux是围绕函数式编程原则构建的。出于各种原因，我们鼓励您将状态保持为普通JS对象和数组，并使用普通函数访问/操作它

我肯定见过许多库试图在Redux之上添加OOP层（例如，其方法转变为动作创建者和还原器的类）。这些都是可行的，但肯定与Redux的整体精神背道而驰

实际上，我使用了一个名为的库，它允许您定义模型类，这些模型类充当存储中普通JS对象的外观。然而，与我见过的许多其他库不同，它与Redux一起工作，而不是试图改变Redux的行为。我在我的博客文章和文章中讨论了Redux ORM是如何工作的，我是如何使用它的，以及为什么它仍然是相当地道的。总的来说，它是帮助管理Redux商店中的关系和规范化数据的极好工具

最后，我目前正在写一篇博客文章，讨论Redux需要的实际技术限制（以及原因），与打算如何使用Redux，以及如何使用Redux。我希望在下个星期左右完成这项工作，请密切关注。

我将通过描述我最终做了什么来回答我自己的问题，尽管这并不完美

首先，我开始使用ES6类语法，而不是常规的ES6类语法，它比ES6类更难看，但更灵活

不过，我的复杂对象主要以两种形式存在：

• 用于存储的普通JS对象
• 类（实际标记的）实例，以便使用实例方法

我使用一种惯例，在所有对普通对象的引用前面加一个_下划线