我知道Redux是一个不错的选择。在考虑是否使用Redux时,我一直在寻找关于缺点和优点的文章,但最近的文章很少。旧文章的内容我不能同意。
文章说样板代码和性能是Redux的缺点。但是,现在是真的吗?
封装
在redux结构中,我可以访问任何数据(无封装)。但是,我没有。这取决于开发人员的能力,我可以随心所欲地关心封装。
内聚力
当我使用redux时,我的代码更有凝聚力。数据突变逻辑被放置在每个特征的切片中。
锅炉板代码
我确实必须在redux结构中将代码作为redux方式。我不得不用Redux结构写更多的代码,但这有点难。相反,使用Redux时可以重复使用更多的零件。当我们在后端制作控制器时,我们会以依赖于框架的方式制作代码。由于设计灵活,几乎没有人能从很低的级别制造控制器。
性能
我已经使用react redux为一些复杂的用例创建了视图。但是,我可以在下面找到有意义的表现。我认为由于数百KB的Redux包而导致性能下降也是没有意义的。
所以我的问题是…
- 我读到的关于Redux cons的文章是两年前写的。现在,使用Redux工具包已成为一种标准方式。Boilerplate代码仍然是Redux的骗局
- 如果性能下降是Redux的问题,你能告诉我具体的例子吗?(什么样的项目在使用redux时会出现性能问题,或者因为性能原因而不使用redux的情况。)
- 今天使用Redux最大的缺点是什么?(除了很难)
任何其他想法或意见,请告诉我。
在考虑是否使用Redux时,我一直在寻找关于缺点和优点的文章,但最近很少有文章
不同的模式和体系结构没有单独的优缺点,它们只有与其他一些体系结构或模式相比的优缺点。到目前为止,你只写过关于Redux的文章——你需要先把它与一些东西进行比较。
文章说样板代码和性能是Redux的缺点。但是,现在是真的吗?
对需要样板代码的指责并不是对我熟悉的Redux的批评。相反,与旧的通量模式相比,Redux实际上减少了样板。
封装:在redux结构中,我可以访问任何数据(无封装)。但是,我没有。这取决于开发人员的能力,我可以随心所欲地关心封装。
- 归咎于JavaScript,而非Redux。在JavaScript中,所有对象(通常)都是可见的:我认为这是一个优势,因为它使脚本可以自定义和破解,而尝试自定义第三方Java或.NET库(对象封装是常态)即使不是不可能,也是非常困难的
- 能够访问状态存储中的所有数据是经过设计的。在Redux(和React)中,您的状态存储是应用程序数据的标准化表示,因此完全可以访问它是有意义的。任意限制组件可以读取的数据是没有意义的(这不像你在运行不受信任的代码)
- 请记住,Redux和React中的状态是不可变的(即,您无法在位编辑数据),因此暴露所有内容不会带来任何风险,因为行为不端的组件无法在位编辑状态。
- 公平地说,你需要使用
Object.freeze
来使数据真正不可变,我想大多数人都忘记了这一点
- 公平地说,你需要使用
- 封装,作为系统设计的一个属性,可能是一件好事,也可能是坏事。当您需要隐藏与正在建模的数据正交(或完全无关)的内部实现细节时,封装通常是有意义的,例如
Array<T>
的内部缓冲区指针或Map<K,V>
的哈希表桶。但是,考虑到在JavaScript中,这些类型(Array
、Map
等)是内置的,您可以使用它们来建模您的不可变状态:您无法查看Map
的bucket或Array
的内部指针,因此实际上您从未停止使用封装的对象
内聚:当我使用redux时,我的代码具有更强的内聚性。数据突变逻辑被放置在每个特征的切片中。
我想你误解了什么"内聚性";实际上是指在这种情况下。我看不出Redux及其状态还原器的基本设计与任何内聚概念有什么关系。
Boilerplate代码:我确实必须在redux结构中以redux的方式编写代码。我不得不用Redux结构写更多的代码,但这有点难。相反,使用Redux时可以重复使用更多的零件。当我们在后端制作控制器时,我们会以依赖于框架的方式制作代码。由于设计灵活,几乎没有人能从很低的级别制造控制器。
我无法完全理解上面的段落:最后几句与正文的其余部分无关。
也就是说,我很感激Redux和React都需要对减少程序、操作和操作创建者进行大量重复的声明,但我不会将其描述为";Boilerplate"代码,因为那些(重复的)声明的信息论内容仍然很高。
性能:我已经使用react redux为一些复杂的用例创建了视图。但是,我可以在下面找到有意义的表现。我认为由于数百KB的Redux包而导致性能下降也是没有意义的。
- Redux的运行时性能与Redux库的大小无关。你把完全不同的问题混为一谈
- 也就是说,我不知道你从哪里得到了Redux要求你拥有";数百KB";因为我的上一个Redux项目有一个大小为25KB的
redux.js
文件,它被缩小为大小只有6KB的redux.min.js
。- 我假设您指的是
@reduxjs/toolkit
库(它有210KB的源文件,但运行时redux-toolkit.umd.min.js
只有33KB
- 我假设您指的是
关于ReactJS中虚拟DOM功能的性能成本,现在有一些东西要说,但ReactJS不是Redux。当您直接使用Redux时,您可以随意操作DOM,所以这一点没有意义。
此外,还讨论了与原位变异状态相比,必须克隆不可变状态的性能影响,然而,不可变数据具有固有的特性,这意味着您可以通过引用而不是通过值进行安全克隆。由于Redux使用有向(理想情况下是非循环)对象树图来表示不可变状态,因此它利用了对未更改子对象的引用可以安全地传递给新的不可变状态的构造函数这一事实(例如,如果有兆字节的数据均匀分布在标准化状态图中,并且您的操作和reducer只更改单个深度嵌套的对象属性,那么只有大约log n
的数据将被重新分配和复制,而不是整个图。
我读到的关于Redux cons的文章是两年前写的。现在,使用Redux工具包已成为一种标准方式。Boilerplate代码仍然是Redux的骗局?
你在说什么样板?
如果性能下降是Redux的问题,你能告诉我具体的例子吗?(什么样的项目在使用redux时存在性能问题,或者因为性能原因而不使用redux的情况。)
这样想吧:JavaScript远远不是最快或最高效的编程语言(例如,V8 JS引擎将消耗数十兆字节的RAM来运行一个简单的"Hello,World"示例脚本)-鉴于此,我不会太担心JS的一般性能(……至少除了确保您在JS中实现的任何算法都能在O(n log n)
时间或更好的时间内运行之外,什么都不用担心)。
现在使用Redux最大的缺点是什么?(除了很难)
我认为最大的缺点是不得不忍受这样的问题。
任何其他想法或意见,请告诉我。
与不符合任何总体通用架构或编程模式的特定JS脚本相比,人们使用Redux是因为他们希望确保通过JS代码的数据流是一致的、可预测的,并且易于推理。如果你不需要这些好处,那么你可能最好写一些特别的JS。