React-Redux：应该将所有组件状态保存在Redux Store中

说我有一个简单的切换：

当我单击按钮时，颜色组件在红色和蓝色之间切换

我可以通过执行以下操作来达到此结果。

index.js

Button: onClick={()=>{dispatch(changeColor())}}
Color: this.props.color ? blue : red

container.js

connect(mapStateToProps)(indexPage)

action_creator.js

function changeColor(){
 return {type: 'CHANGE_COLOR'}
}

reducer.js

switch(){
case 'CHANGE_COLOR':
return {color: true}

但这是很多代码的地狱，我可以用jQuery，一些类和一些CSS在5秒钟内完成一些事情。

所以我想我真正要问的是，我在这里做错了什么？

Redux主要用于“应用程序状态”。也就是说，任何与您的应用程序逻辑有关的内容。建立在其顶部的视图是该状态的反映，但不必为执行的所有操作仅使用该状态容器。

只需问以下问题：该状态对应用程序的其余部分是否重要？应用程序的其他部分是否会基于该状态而有所不同？在许多较小的情况下，情况并非如此。下拉菜单：打开或关闭的事实可能不会对应用程序的其他部分产生影响。因此，将其连接到您的商店可能是过大的选择。这当然是一个有效的选择，但并没有真正给您带来任何好处。最好this.state每天使用并调用它。

在您的特定示例中，切换按钮的颜色是否会对应用程序的其他部分产生影响？如果它是应用程序主要部分的某种全局开/关切换，则它肯定属于商店。但是，如果您只是在单击按钮时切换按钮颜色，则可以将颜色状态保留为本地定义。单击按钮的动作可能还具有其他需要动作分派的效果，但这与应该使用什么颜色的简单问题是分开的。

通常，请尝试使应用程序状态尽可能小。您不必将所有东西都推到那里。在需要时执行此操作，或者将某些内容保留在其中很有意义。或者，如果使用开发工具可以使您的生活更轻松。但是不要过多地强调它的重要性。

Redux常见问题解答：组织说明Redux
官方文档的这一部分很好地回答了您的问题。

使用本地组件状态很好。作为开发人员，确定应用程序构成哪种状态以及每种状态应驻留的位置是您的工作。找到一个适合您的天平，然后继续前进。

用于确定应将哪种数据放入Redux的一些通用经验法则：

• 应用程序的其他部分是否关心此数据？
• 您是否需要能够基于此原始数据创建其他派生数据？
• 是否使用相同的数据来驱动多个组件？
• 能够将这种状态恢复到给定的时间点（例如，时间旅行调试）对您有价值吗？
• 您是否要缓存数据（即，使用已存在的状态而不是重新请求）？

为了突出显示@ AR7提供的出色链接，并且因为该链接向后移动了一段时间，所以：

将React用于短暂状态，该状态对应用程序全局无关紧要，并且不会以复杂的方式进行更改。例如，在某些UI元素中切换，即表单输入状态。将Redux用于全局重要的状态或以复杂方式突变的状态。例如，缓存的用户或后期草稿。

有时，您可能希望从Redux状态转换为React状态（当在Redux中存储内容变得笨拙时），或者反过来（当更多组件需要访问某些曾经是本地的状态时）。

经验法则是：做些不太尴尬的事情。

丹·阿布拉莫夫（Dan Abramov）：https : //github.com/reactjs/redux/issues/1287#issuecomment-175351978

是的，值得努力将所有组件状态存储在Redux中。如果这样做，您将受益于Redux的许多功能，例如时间旅行调试和可重播的错误报告。如果您不这样做，那么这些功能可能会完全不可用。

每当您不在 Redux中存储组件状态更改时，该更改就会从Redux更改堆栈中完全丢失，并且您的应用程序UI将与存储不同步。如果这对您不重要，请问自己为什么要完全使用Redux？没有它，您的应用程序将不再那么复杂！

出于性能方面的考虑，您可能希望退回可this.setState()重复执行许多操作的任何操作。例如：每次用户键入键时，将输入字段的状态存储在Redux中可能会导致性能下降。您可以通过将其视为事务来解决此问题：用户操作“提交”后，将最终状态保存在Redux中。

您的原始帖子提到Redux方式是如何“编写大量代码的”。是的，但是您可以将抽象用于常见的模式，例如本地组件状态。