所以基本上，我遇到了很多文章，他们提到通过 Flux 或 redux 管理状态。 我想知道 UI 组件有自己的状态怎么样？ 让 redux 管理 Api 调用和成功 toast 消息等是否是一种好习惯，但 UI 组件应该有自己的本地状态？ 请有人详细说明行业中的最佳实践是什么？
【问题讨论】：
标签： javascript reactjs redux components state
在询问了许多专业人士和行业开发人员后，我了解到通过 redux 管理状态取决于您的应用程序范围。 但更重要的是，如果我在做企业应用程序，那么应用程序的状态必须通过 redux 来管理。
现在的问题是应该在我们的 redux 存储中保留什么。好吧，您几乎可以将任何东西存储在 redux 存储中，但也可以更好地管理组件的本地状态。例如，打开一个组件布尔值应该在本地状态或任何字符串或标题名称等中进行管理。
【讨论】：
好问题！答案通常是“视情况而定”，但在某些情况下，您可能更愿意使用其中一种。
使用 Redux 存储与应用程序相关的状态。例如。应该显示的当前页面/面板。正如您所提到的，显示通知/消息 - 存储在 redux 状态中是有意义的，因为替代方案是在整个地方传递状态，例如一个错误提示冒泡到您的根组件，它呈现吐司消息。当您获取/操作与整个应用程序相关的数据时，使用 thunk 也是一个好主意，例如出现在多个地方的事物列表。
使用组件状态来存储仅与组件相关的状态。也就是说，如果您正在填写表单，则将文本输入、复选框等的值存储在组件状态中（可能与 container and presentational components 一起使用）是有意义的，因为此时的值与应用程序的其余部分。
【讨论】：
虽然这个问题需要征求意见，但我将留下我的答案。对此没有标准的最佳实践。如果有多个人编写代码，则归结为团队的便利性和基本规则。
我经常使用 Redux。但是，我不会避免在组件中使用本地状态。
像输入 onChange 处理程序这样的表单处理需要本地状态。对 onChange 处理程序使用全局状态并不高效。
可重用组件使用本地状态。同样，它归结为可重用性是技术可重用性还是业务可重用性。如果您正在开发自定义滚动条组件，请使用本地状态。但是，如果您使用在应用程序中随处使用的评论表单，请使用全局状态。
我更喜欢让大部分内容处于全局状态。我也使用 redux thunk。在 redux thunk 中，可以在 thunk 函数中访问全局状态。这非常有用，因为它避免了对到处传递的道具/上下文的依赖。
我确实在本地状态中保留了一些简单的东西——例如，显示/隐藏一些东西。在使用本地状态隐藏一些东西之前，我不介意等待承诺解决。
总体而言，使用全局状态与本地状态的决定主要是基于方便性。除了您和您的团队感到满意之外，没有其他标准规则。
React 是一种以声明方式处理 UI 的方法。框架有一些规则，例如状态、道具、上下文。基于这些原语使 UI 具有声明性和高性能由开发人员决定。开发人员如何做并不重要，只要代码可维护并被他人理解即可。
【讨论】：