使用Redux进行组件状态管理

时间:2018-12-07 07:32:54

标签: javascript reactjs redux components state

因此,基本上,我碰到过很多文章,它们都是通过flux或redux来管理状态。 我想知道UI组件具有自己的状态吗?让redux管理Api调用和成功的Toast消息等是一种好习惯吗,但是UI组件应该具有自己的本地状态? 请有人详细说明什么是行业最佳实践?

3 个答案:

答案 0 :(得分:0)

尽管这个问题需要征求意见,但我将留下我的答案。对此没有标准的最佳实践。如果编写代码的人不止一个人,那么这归结为团队的便利性和基本规则。

我经常使用Redux。但是,我不会在组件中使用局部状态。

像输入onChange处理程序这样的表单处理要求局部状态。使用onChange处理程序的全局状态是无效的。

可重用组件使用本地状态。同样,归结为可重用性是技术可重用性还是业务可重用性。如果要开发自定义滚动条组件,请使用本地状态。但是,如果使用的注释表单在应用程序中到处使用,请使用全局状态。

我更喜欢将大多数东西放在全球状态。我也使用redux thunk。在redux thunk中,可以在thunk函数内访问全局状态。这非常有用,因为它避免了对props / context的依赖。

我确实将一些简单的东西保持在本地状态-例如,显示/隐藏一些东西。我不介意在使用本地状态隐藏某些内容之前等待承诺解决。

总体而言,使用全局状态还是局部状态的决定主要是基于便利性。除了您和您​​的团队可以接受的标准之外,没有其他标准规则。

React是一种声明式处理UI的方法。框架中有一些规则,例如状态,道具,上下文。留给开发人员根据这些原语使UI声明性和高性能。只要代码可以被他人维护和理解,开发人员如何做就无关紧要。

答案 1 :(得分:0)

好问题!答案通常是“视情况而定”,但是在明显的情况下,您可能更愿意使用一种方法。

使用Redux来存储与应用程序相关的状态。例如。当前应显示的页面/面板。如您所提到的那样,显示通知/消息-在redux状态下存储是有意义的,因为替代方案是在整个地方传递状态,例如一个错误提示冒泡到您的根组件,该根组件呈现了Toa​​st消息。当您获取/处理与整个应用相关的数据时,例如,使用thunk也是一个好主意。出现在几个地方的东西的列表。

使用组件状态来存储仅与组件相关的状态。也就是说,如果您要填写表单,则在组件状态(可能与container and presentational components结合使用)中存储文本输入,复选框等的值是有意义的,因为此时的值不是与应用程序的其余部分有关。

答案 2 :(得分:0)

问了很多专业人士和行业开发人员之后,我才知道通过redux管理状态取决于您的应用程序范围。 但更重要的是,如果我正在处理企业应用程序,则必须通过redux管理应用程序状态。

现在的问题是,我们的redux商店应该保留什么。好吧,您几乎可以将所有内容存储在redux存储中,但更好地管理组件的本地状态。例如,打开组件布尔值应在本地状态或任何字符串或标头名称等中进行管理。