首页
学习
活动
专区
圈层
工具
发布
社区首页 >问答首页 >“提升状态向上”与Redux、流量状态管理的比较

“提升状态向上”与Redux、流量状态管理的比较
EN

Stack Overflow用户
提问于 2018-05-14 12:59:22
回答 5查看 3.3K关注 0票数 11

我理解反应提升状态上升的"https://reactjs.org/docs/lifting-state-up.html“。通过这种方法,开发人员需要将父母中的状态函数作为道具传递给孩子。在那之后,我做了几次关于redux的讨论。但是,我无法理解提升状态与Redux,流量状态管理在简单比较中的主要区别。

  1. 这是否意味着在一个大型web应用程序中不应该使用“提升状态”,并且不可避免地会出现剩余/流。
  2. Redux简化了状态管理的整个过程,但除了抽象和简化之外,还有其他优点吗?
  3. 与“提升状态”相比,通过使用Redux,我们将有一个真理的来源,即我们需要将状态保持在多个组件中,从而增加了整个代码的复杂性。在提升状态时,您可以有一个单一的真理来源,这种方法的唯一缺点将是您的父组件将被许多状态杂乱。
  4. 在redux和提升状态之间是否存在性能角度?
  5. 如果React被认为是一个视图库,那么它应该首先给出一个状态管理选项吗?
EN

回答 5

Stack Overflow用户

发布于 2018-05-14 13:15:59

这是否意味着在一个大型web应用程序中不应该使用“提升状态”,并且不可避免地会出现剩余/流。

绝对不需要,您需要使用redux/通量,只有当应用程序使用的数据在许多没有共享足够接近的父级的组件之间共享时,并且数据不断变化,视图需要刷新。

如果在应用程序的一个小部分中共享数据,您也可以考虑为此目的使用Context-API

Redux简化了状态管理的整个过程,但除了抽象和简化之外,还有其他优点吗?

是的,redux提供了一个广泛的优势

  • 将状态持久化到本地存储,然后从它启动,不加任何限制。
  • 服务器上的预填充状态,用HTML将其发送到客户端,然后从它启动,从盒子中取出。
  • 序列化用户操作,并将它们与状态快照一起附加到自动错误报告中,以便产品开发人员可以重放它们以再现错误。
  • 通过网络传递操作对象,以实现协作环境,而不会对代码的编写方式进行重大更改。

与“提升状态”相比,通过使用Redux,我们将有一个真理的来源,即我们需要将状态保持在多个组件中,从而增加了整个代码的复杂性。在提升状态时,您可以有一个单一的真理来源,这种方法的唯一缺点将是您的父组件将被许多状态杂乱。

如前所述,如果数据在没有非常直接的共同祖先的组件之间共享,您可能更喜欢Redux。Redux还提供了一个优势,即它将连接实现为PureComponent,因此状态更新只会影响正在使用它们的组件,并且不会对其他不使用这些特定状态作为支持的组件重新呈现。

提升状态后,您需要通过每个组件向下传递值,然后需要确保中间组件是纯的。

在redux和提升状态之间是否存在性能角度?

当您正在传递状态并不使用PureComponents时,性能问题就会出现,这会导致不必要的重新呈现。Redux在这里很有用

票数 5
EN

Stack Overflow用户

发布于 2018-05-14 13:22:11

Redux仅仅是一种抽象,它没有给出任何您自己无法实现的性能优化。

然而,为了实现Redux提供的开箱即用的性能优化,您需要做很多工作,比如为几乎每个组件实现shouldComponentUpdate

例如,如果某些组件需要共享公共状态,则必须将状态提升到组件之间的公共父级。父组件和不使用共享状态的组件之间的每个其他组件都需要通过shouldComponentUpdate忽略与该状态相关的更改。

每个组件还需要实现shouldComponentUpdate/PureComponent来检查其道具是否更改,否则当父组件重新呈现时,所有子组件都会自动重新呈现。

Redux还提供了其他一些方便特性:

  • 不需要通过深嵌套组件传递回调和支持。
  • 用于可视化状态更改、时间移动调试等的Redux DevTools
  • 通过localStorage直接持久化状态到保留-持久化
  • action /树干表示/容器模式等的使用提高了代码的可重用性、可测试性和可维护性。
票数 2
EN

Stack Overflow用户

发布于 2018-05-15 04:53:00

这里已经有了一些很好的答案。我将采取更务实的方法:

Redux为您的所有状态提供了一个单一的真理来源,尽管当您拆分减速器时,它可能变得完全不同。

组件状态意味着应用程序状态自然更加不同,但正如您所提到的,部分将通过提升状态来集中。

您在项目中管理状态的方式将随着时间的推移而发展。您管理状态的方式也应该以您正在编写的应用程序为指导。

还请注意,Redux和提升状态根本不是相互排斥的技术--您可以适当地使用这两种技术。

对于新项目,我权衡了将所有状态都放在一个位置(单一的真实来源)与必须编写操作和连接组件的不便开销之间的关系。

如果有疑问,我建议从组件状态开始,将其提升为一层-两层,然后将其提升到redux存储并直接连接我的组件。这使您以务实的方式了解这两种方法的好处。

集中式redux存储的工具和单例特性意味着免费获得各种特性(持久性、时间旅行、redux等)。另一方面,我可能会浪费相当多的时间在早期用redux连接应用程序,而更容易忘记我坐下来编写的东西。

票数 2
EN
页面原文内容由Stack Overflow提供。腾讯云小微IT领域专用引擎提供翻译支持
原文链接:

https://stackoverflow.com/questions/50330954

复制
相关文章

相似问题

领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档