Redux 的真正缺点是什么？
What are the true cons of Redux?
我知道 Redux 是一个不错的选择。
在考虑要不要用Redux的时候，一直在找关于利弊的文章，但是最近的文章很少。旧文有不能认同的内容
文章说样板代码和性能是 Redux 的缺点。但是，现在也是这样吗？
封装
在 redux 结构中，我可以访问任何数据（无封装）。但是，我没有。就看开发者的能力了，我想怎么封装就怎么关心。
凝聚力
当我使用 redux 时，我的代码更有凝聚力。每个特征的数据变异逻辑都放在切片中。
样板代码
我确实必须在 Redux 结构中将代码编写为 redux 方式。
我不得不在 Redux 结构中多写一点代码，但只是一点点。相反，使用 Redux 时可以重用更多的部分。
当我们在后端制作控制器时，我们以依赖于框架的方式编写代码。由于设计灵活，几乎没有人从很低的层次开始做控制器。
性能
我已经使用 react-redux 对一些复杂的用例进行了查看。但是，我可以找到有意义的表现。我认为由于数百 KB 的 Redux 包而导致性能下降也是没有意义的。
所以我的问题是...
- 我看过的关于 Redux cons 的文章是 2 年前写的。使用 Redux 工具包是现在的标准方式。样板代码仍然是 Redux 的缺点？
- 如果性能下降是 Redux 的问题，你能告诉我具体的例子吗？ （什么样的项目在使用redux时出现性能问题，或者因为性能问题没有使用Redux的案例。）
- 今天使用 Redux 的最大缺点是什么？ （除了很难）
任何其他想法或意见，请告诉我。
While thinking about whether to use Redux or not, I was looking for articles about cons and pros, but there were few recent articles
不同的模式和架构没有孤立的优缺点，它们只有与其他架构或模式相比才有优缺点。到目前为止，您只写了有关 Redux 的文章 - 您需要先将其与某些东西进行比较。
The articles say that boilerplate code and performance are cons of Redux. but, Is it true even now?
需要样板代码的指责并不是我所熟悉的对 Redux 的批评。相反，Redux actually reduces boilerplate compared to the older Flux pattern.
Encapsulation: In redux structure, I could access any data (No encapsulation). but, I didn't. It depends on the developer's capabilities and I can care about encapsulation as much as I want.
- 怪Java脚本，而不是 Redux。在 JavaScript 中，所有对象（通常）都是可见的：我认为这是一个优势，因为它使脚本可定制和可破解，而尝试定制第三方 Java 或 .NET 库（其中对象封装是常态）即使不是不可能也是非常困难的。
- 能够访问状态存储中的所有数据是设计使然。在 Redux（和 React）中，您的应用程序数据的状态存储 is meant to be a normalized representation，因此完全可访问它是有意义的。任意限制组件可以读取的数据是没有意义的（这不像是 运行ning 不受信任的代码）。
- 请记住 Redux 和 React 中的状态是不可变的（即您无法就地编辑数据），因此公开所有内容不会带来任何风险，因为行为不当的组件 不能 就地编辑状态。
- 公平地说，您需要使用
Object.freeze 使数据真正不可变，我想大多数人都忘记了...
- 作为系统设计的 属性，封装可以是好事，也可以是坏事。当您需要隐藏与正在建模的数据正交（或完全不相关）的内部实现细节时，封装通常 有意义 ，例如
Array<T> 的内部缓冲区指针或 Map<K,V> 的哈希表桶。但是请考虑在 JavaScript 中，这些类型（Array、Map 等）是内置的，您可以使用它们来模拟您的不可变状态：您无法看到 Map 的桶或 Array 的内部指针，所以你实际上 从未停止使用 封装对象。
Cohesion: When I used redux, My code had more cohesion. Data mutation logic is placed in the slice for every feature.
我想你误解了什么"cohesion" actually means in this context。我看不出 Redux 及其状态缩减器的基本设计如何与任何内聚概念相关。
Boilerplate code: I indeed have to make code as the redux way in the Redux structure. I had to write a little more code in Redux structure, but it was a little bit. Rather, more parts can be reused when using Redux. When we make a controller in the back-end, we make code in a framework-dependent way. There is almost no one who makes the controller from very low levels because of the flexible design.
我无法完全理解上面的段落：最后几句与正文的其余部分无关。
也就是说，我很欣赏 Redux 和 React 都需要相当多的重复性 声明 用于 reducer、action 和 action-creators，但我不会将其描述为“样板”代码，因为那些（重复的）声明的 信息理论内容 仍然很高。
Performance: I have made views for some complex use-cases using react-redux. but, I could find meaningful performance down. I think it is also meaningless that there is a performance down due to hundreds of KB of Redux packages.
- Redux 的运行时间性能与 Redux 库的大小无关。您将完全不同的问题混为一谈。
- 就是说，我不知道你从哪里得到 Redux 要求你拥有“数百 KB”的 JS 文件的想法，因为我的上一个 Redux 项目有一个
redux.js 大小的文件25KB，缩小到 redux.min.js，大小只有 6KB。
- 我假设您指的是
@reduxjs/toolkit 库（它有 210KB 的源文件，但是 运行time redux-toolkit.umd.min.js 只有 33KB.
现在 关于 ReactJS 中虚拟 DOM 功能的性能成本有一些要说的，但 ReactJS 不是 Redux。当您直接使用 Redux 时，您可以随意操作 DOM - 所以这一点没有实际意义。
还有一个讨论是关于必须克隆不可变状态与就地改变状态相比的性能影响，但是不可变数据具有固有的特性，这意味着您可以安全地按引用克隆而不是克隆- 按价值。而且因为 Redux 使用有向（理想情况下是非循环的）对象树图来表示不可变状态，所以它利用了这样一个事实，即对未更改的子对象的引用可以安全地传递给新的不可变状态的构造函数（例如，如果你有兆字节数据均匀分布在您的 规范化 状态图中，并且您的操作和缩减程序仅更改单个深层嵌套对象 属性，那么只有大约 log n 数据将被重新分配和复制，而不是整个图形。
The articles about Redux cons I read were written 2 years ago. Using the Redux toolkit is a standard way now. Boilerplate code still is a con of Redux?
你在说什么样板？
If the performance down is a con of Redux, Could you tell me specific examples? (What kind of project has performance problems when using redux, or the cases that don't use Redux because of performance.)
这样想：JavaScript 远非最快或最高效的编程语言（例如，V8 JS 引擎将消耗数十兆字节的 RAM 运行一个简单的“Hello, World”示例脚本） - 鉴于此，我不会太担心 JS 的一般性能（......至少除了确保你在 JS 运行 中实现的任何算法之外没有什么 O(n log n) 时间或更好）。
What is the biggest con of using Redux today? (Except that it's hard)
我想说最大的缺点就是不得不忍受这样的问题。
Any other thoughts or opinions, please let me know.
人们使用 Redux 是因为他们想确保通过他们的 JS 代码的数据流是一致的、可预测的，并且与不符合任何整体通用架构或编程的临时 JS 脚本相比，可以直接推理模式。如果您不需要这些好处，那么您 可能 最好还是编写 ad-hoc JS。
我知道 Redux 是一个不错的选择。 在考虑要不要用Redux的时候，一直在找关于利弊的文章，但是最近的文章很少。旧文有不能认同的内容
文章说样板代码和性能是 Redux 的缺点。但是，现在也是这样吗？
封装
在 redux 结构中，我可以访问任何数据（无封装）。但是，我没有。就看开发者的能力了，我想怎么封装就怎么关心。
凝聚力
当我使用 redux 时，我的代码更有凝聚力。每个特征的数据变异逻辑都放在切片中。
样板代码
我确实必须在 Redux 结构中将代码编写为 redux 方式。 我不得不在 Redux 结构中多写一点代码，但只是一点点。相反，使用 Redux 时可以重用更多的部分。 当我们在后端制作控制器时，我们以依赖于框架的方式编写代码。由于设计灵活，几乎没有人从很低的层次开始做控制器。
性能
我已经使用 react-redux 对一些复杂的用例进行了查看。但是，我可以找到有意义的表现。我认为由于数百 KB 的 Redux 包而导致性能下降也是没有意义的。
所以我的问题是...
- 我看过的关于 Redux cons 的文章是 2 年前写的。使用 Redux 工具包是现在的标准方式。样板代码仍然是 Redux 的缺点？
- 如果性能下降是 Redux 的问题，你能告诉我具体的例子吗？ （什么样的项目在使用redux时出现性能问题，或者因为性能问题没有使用Redux的案例。）
- 今天使用 Redux 的最大缺点是什么？ （除了很难）
任何其他想法或意见，请告诉我。
While thinking about whether to use Redux or not, I was looking for articles about cons and pros, but there were few recent articles
不同的模式和架构没有孤立的优缺点，它们只有与其他架构或模式相比才有优缺点。到目前为止，您只写了有关 Redux 的文章 - 您需要先将其与某些东西进行比较。
The articles say that boilerplate code and performance are cons of Redux. but, Is it true even now?
需要样板代码的指责并不是我所熟悉的对 Redux 的批评。相反，Redux actually reduces boilerplate compared to the older Flux pattern.
Encapsulation: In redux structure, I could access any data (No encapsulation). but, I didn't. It depends on the developer's capabilities and I can care about encapsulation as much as I want.
- 怪Java脚本，而不是 Redux。在 JavaScript 中，所有对象（通常）都是可见的：我认为这是一个优势，因为它使脚本可定制和可破解，而尝试定制第三方 Java 或 .NET 库（其中对象封装是常态）即使不是不可能也是非常困难的。
- 能够访问状态存储中的所有数据是设计使然。在 Redux（和 React）中，您的应用程序数据的状态存储 is meant to be a normalized representation，因此完全可访问它是有意义的。任意限制组件可以读取的数据是没有意义的（这不像是 运行ning 不受信任的代码）。
- 请记住 Redux 和 React 中的状态是不可变的（即您无法就地编辑数据），因此公开所有内容不会带来任何风险，因为行为不当的组件 不能 就地编辑状态。
- 公平地说，您需要使用
Object.freeze使数据真正不可变，我想大多数人都忘记了...
- 公平地说，您需要使用
- 作为系统设计的 属性，封装可以是好事，也可以是坏事。当您需要隐藏与正在建模的数据正交（或完全不相关）的内部实现细节时，封装通常 有意义 ，例如
Array<T>的内部缓冲区指针或Map<K,V>的哈希表桶。但是请考虑在 JavaScript 中，这些类型（Array、Map等）是内置的，您可以使用它们来模拟您的不可变状态：您无法看到Map的桶或Array的内部指针，所以你实际上 从未停止使用 封装对象。
Cohesion: When I used redux, My code had more cohesion. Data mutation logic is placed in the slice for every feature.
我想你误解了什么"cohesion" actually means in this context。我看不出 Redux 及其状态缩减器的基本设计如何与任何内聚概念相关。
Boilerplate code: I indeed have to make code as the redux way in the Redux structure. I had to write a little more code in Redux structure, but it was a little bit. Rather, more parts can be reused when using Redux. When we make a controller in the back-end, we make code in a framework-dependent way. There is almost no one who makes the controller from very low levels because of the flexible design.
我无法完全理解上面的段落：最后几句与正文的其余部分无关。
也就是说，我很欣赏 Redux 和 React 都需要相当多的重复性 声明 用于 reducer、action 和 action-creators，但我不会将其描述为“样板”代码，因为那些（重复的）声明的 信息理论内容 仍然很高。
Performance: I have made views for some complex use-cases using react-redux. but, I could find meaningful performance down. I think it is also meaningless that there is a performance down due to hundreds of KB of Redux packages.
- Redux 的运行时间性能与 Redux 库的大小无关。您将完全不同的问题混为一谈。
- 就是说，我不知道你从哪里得到 Redux 要求你拥有“数百 KB”的 JS 文件的想法，因为我的上一个 Redux 项目有一个
redux.js大小的文件25KB，缩小到redux.min.js，大小只有 6KB。- 我假设您指的是
@reduxjs/toolkit库（它有 210KB 的源文件，但是 运行timeredux-toolkit.umd.min.js只有 33KB.
- 我假设您指的是
现在 关于 ReactJS 中虚拟 DOM 功能的性能成本有一些要说的，但 ReactJS 不是 Redux。当您直接使用 Redux 时，您可以随意操作 DOM - 所以这一点没有实际意义。
还有一个讨论是关于必须克隆不可变状态与就地改变状态相比的性能影响，但是不可变数据具有固有的特性，这意味着您可以安全地按引用克隆而不是克隆- 按价值。而且因为 Redux 使用有向（理想情况下是非循环的）对象树图来表示不可变状态，所以它利用了这样一个事实，即对未更改的子对象的引用可以安全地传递给新的不可变状态的构造函数（例如，如果你有兆字节数据均匀分布在您的 规范化 状态图中，并且您的操作和缩减程序仅更改单个深层嵌套对象 属性，那么只有大约 log n 数据将被重新分配和复制，而不是整个图形。
The articles about Redux cons I read were written 2 years ago. Using the Redux toolkit is a standard way now. Boilerplate code still is a con of Redux?
你在说什么样板？
If the performance down is a con of Redux, Could you tell me specific examples? (What kind of project has performance problems when using redux, or the cases that don't use Redux because of performance.)
这样想：JavaScript 远非最快或最高效的编程语言（例如，V8 JS 引擎将消耗数十兆字节的 RAM 运行一个简单的“Hello, World”示例脚本） - 鉴于此，我不会太担心 JS 的一般性能（......至少除了确保你在 JS 运行 中实现的任何算法之外没有什么 O(n log n) 时间或更好）。
What is the biggest con of using Redux today? (Except that it's hard)
我想说最大的缺点就是不得不忍受这样的问题。
Any other thoughts or opinions, please let me know.
人们使用 Redux 是因为他们想确保通过他们的 JS 代码的数据流是一致的、可预测的，并且与不符合任何整体通用架构或编程的临时 JS 脚本相比，可以直接推理模式。如果您不需要这些好处，那么您 可能 最好还是编写 ad-hoc JS。