Redux 的真正缺点是什么？

Question

我知道 Redux 是一个公正的选择。 在考虑是否使用 Redux 时，我一直在寻找有关利弊的文章，但最近的文章很少。旧文章有我不能同意的内容。

文章说样板代码和性能是 Redux 的缺点。但是，现在也是这样吗？

封装

在 redux 结构中，我可以访问任何数据（无封装）。但是，我没有。这取决于开发人员的能力，我可以随心所欲地关心封装。

凝聚力

当我使用 redux 时，我的代码更有凝聚力。数据变异逻辑被放置在每个特征的切片中。

样板代码

我确实必须在 Redux 结构中以 redux 方式编写代码。 我不得不在 Redux 结构中多写一点代码，但还是有一点点。相反，在使用 Redux 时可以重用更多的部分。 当我们在后端制作控制器时，我们以依赖框架的方式制作代码。由于设计灵活，几乎没有人从非常低的水平制作控制器。

性能

我已经使用 react-redux 为一些复杂的用例创建了视图。但是，我可以找到有意义的表现。我认为数百KB的Redux包导致性能下降也是没有意义的。

所以我的问题是......

• 我读到的关于 Redux 缺点的文章是 2 年前写的。现在使用 Redux 工具包是一种标准方式。样板代码仍然是 Redux 的弊端？
• 如果性能下降是 Redux 的弊端，你能告诉我具体的例子吗？ （什么样的项目在使用redux的时候会出现性能问题，或者因为性能问题不使用redux的情况。）
• 今天使用 Redux 的最大缺点是什么？ （除了很难）

任何其他想法或意见，请告诉我。

Answer 1

在考虑是否使用 Redux 时，我正在寻找有关利弊的文章，但最近的文章很少

不同的模式和架构没有孤立的优缺点，与其他一些架构或模式相比，它们只有优缺点。到目前为止，您只写过有关 Redux 的文章——您需要先将其与某些东西进行比较。

文章说样板代码和性能是 Redux 的缺点。但是，现在也是这样吗？

需要样板代码的指责并不是对我熟悉的 Redux 的批评。相反，Redux actually reduces boilerplate compared to the older Flux pattern。

封装：在 redux 结构中，我可以访问任何数据（无封装）。但是，我没有。这取决于开发人员的能力，我可以随心所欲地关心封装。

1. 责备 JavaScript，而不是 Redux。在 JavaScript 中，所有对象（通常）都对全世界可见：我认为这是一种优势，因为它使脚本可定制和可破解，而尝试自定义第三方 Java 或 .NET 库（其中对象封装是规范）是即使不是不可能，也非常困难。
2. 能够访问状态存储中的所有数据是设计使然。在 Redux（和 React）中，您的应用程序数据的状态存储 is meant to be a normalized representation，因此完全可访问它是有意义的。任意限制组件可以读取的数据是没有意义的（这不像您在运行不受信任的代码）。
3. 请记住，Redux 和 React 中的状态是不可变的（即您不能就地编辑数据），因此暴露所有内容不会带来任何风险，因为行为不端的组件不能 em> 就地编辑状态。
   • 公平地说，您需要使用Object.freeze 使数据真正不可变，我想大多数人都忘记这样做了...
4. 封装作为系统设计的一个属性，可能是好事，也可能是坏事。当您需要隐藏与正在建模的数据正交（或完全不相关）的内部实现细节时，封装通常有意义，例如 Array<T> 的内部缓冲区指针或 @987654327 @ 的哈希表桶。但考虑到在 JavaScript 中这些类型（Array、Map 等）是内置的，您可以使用它们来模拟您的不可变状态：您无法看到 Map 的存储桶或 Array' s 内部指针，因此您实际上从未停止使用封装对象。

内聚力：当我使用 redux 时，我的代码更有内聚力。数据变异逻辑被放置在每个特征的切片中。

我想你误解了"cohesion" actually means in this context 的意思。我看不出 Redux 的基本设计及其 state-reducers 与任何内聚概念有何关联。

样板代码：我确实得把代码做成Redux结构中的redux方式。我不得不在 Redux 结构中多写一点代码，但还是有一点点。相反，在使用 Redux 时可以重用更多的部分。当我们在后端制作控制器时，我们以依赖框架的方式制作代码。由于设计灵活，几乎没有人从非常低的水平制作控制器。

我无法完全理解上面的段落：最后几句话与正文的其余部分无关。

也就是说，我很欣赏 Redux 和 React 都需要对 reducer、action 和 action-creators 进行相当多的重复声明，但我不会将其描述为“样板”代码，因为那些（重复的）声明的信息论内容仍然很高。

性能：我使用 react-redux 为一些复杂的用例制作了视图。但是，我可以找到有意义的表现。我认为数百KB的Redux包导致性能下降也是没有意义的。

• Redux 的运行时性能与 Redux 库的大小无关。您将完全不同的问题混为一谈。
• 也就是说，我不知道您从哪里得到 Redux 要求您拥有“数百 KB”JS 文件的想法，因为我的上一个 Redux 项目有一个大小为 25KB 的 redux.js 文件，即缩小为 redux.min.js，大小仅为 6KB。
  • 我假设您指的是 @reduxjs/toolkit 库（它有 210KB 的源文件，但运行时 redux-toolkit.umd.min.js 只有 33KB。

现在要说一下 ReactJS 中虚拟 DOM 功能的性能成本，但 ReactJS 不是 Redux。当您直接使用 Redux 时，您可以随意操作 DOM - 所以这一点没有实际意义。

还有一个关于必须克隆不可变状态与就地突变状态相比的性能影响的讨论，但是不可变数据具有固有特性，这意味着您可以安全地通过引用克隆而不是通过克隆-价值。而且因为 Redux 使用有向（理想情况下是非循环的）对象树图来表示不可变状态，它利用了对未更改子对象的引用可以安全地传递给新的不可变状态的构造函数这一事实（例如，如果你有兆字节数据均匀分布在您的 规范化 状态图中，并且您的操作和化简器仅更改单个深度嵌套的对象属性，那么将重新分配和复制唯一关于 log n 的数据，而不是整个图表。

我读到的关于 Redux 缺点的文章是 2 年前写的。现在使用 Redux 工具包是一种标准方式。样板代码仍然是 Redux 的骗局？

你在说什么样板文件？

如果性能下降是 Redux 的弊端，你能告诉我具体的例子吗？ （什么样的项目在使用redux的时候会出现性能问题，或者因为性能问题不使用redux的情况。）

这样想：JavaScript 远非最快或最高效的编程语言（例如，V8 JS 引擎将消耗数十兆字节的 RAM，只是为了运行一个简单的“Hello, World”示例脚本） -鉴于此，我不会太担心 JS 中的一般性能（...至少除了确保您在 JS 中实现的任何算法在O(n log n) 时间或更好的时间内运行之外，别无所求。

今天使用 Redux 的最大缺点是什么？ （除了很难）

我想说最大的缺点是不得不忍受这样的问题。

任何其他想法或意见，请告诉我。

人们使用 Redux 是因为与不符合任何总体通用架构或编程模式的临时 JS 脚本相比，他们希望确保通过其 JS 代码的数据流是一致的、可预测的且易于推理。如果您不需要这些好处，那么您可能最好还是编写 ad-hoc JS。