说我有一个简单的切换：
单击按钮时，“颜色”组件在红色和蓝色之间变化
通过做这样的事情，我可能会达到这个结果。
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并将其称为一天。
在您的特定示例中，该按钮的颜色是否会切换为在应用程序的其他部分中产生任何差异？如果它是应用程序主要部分的某种全局开/关切换，它肯定属于商店。但是，如果您只是在单击按钮时切换按钮颜色，则可以将颜色状态保留在本地定义。单击按钮的操作可能具有需要操作调度的其他效果，但这与应该是什么颜色的简单问题是分开的。
通常，尽量保持应用程序状态尽可能小。你不必把所有东西都塞进去。在必要时这样做或者在那里保留一些东西很有意义。或者，如果它在使用Dev Tools时让您的生活更轻松。但是不要过分重视它的重要性。
Redux FAQ: Organizing State redux官方文档的这一部分很好地回答了你的问题。
使用本地组件状态很好。作为开发人员，您的工作是确定应用程序的状态，以及每个州应该居住的位置。找到适合您的天平，并配合它。
确定应将哪种数据放入Redux的一些常用经验法则：
- 应用程序的其他部分是否关心此数据？
- 您是否需要能够基于此原始数据创建更多派生数据？
- 是否使用相同的数据来驱动多个组件？
- 能够将此状态恢复到给定时间点（即时间旅行调试）是否对您有价值？
- 您是否要缓存数据（即，如果已经存在，则使用处于状态的状态而不是重新请求数据）？
为了突出@ AR7提供的优秀链接，并且因为该链接移动了一段时间：
将React用于对全局应用程序无关紧要的短暂状态，并且不会以复杂的方式进行变异。例如，某个UI元素中的切换，表单输入状态。将Redux用于全局重要或以复杂方式变异的状态。例如，缓存用户或帖子草稿。
有时你会想要从Redux状态转移到React状态（当在Redux中存储某些东西变得笨拙时）或者反过来（当更多组件需要访问某些曾经是本地的状态时）。
经验法则是：做任何不那么尴尬的事情。
阿布拉莫夫：https://github.com/reactjs/redux/issues/1287#issuecomment-175351978
是的，值得努力将所有组件状态存储在Redux中。如果您这样做，您将受益于Redux的许多功能，如时间旅行调试和可重放的错误报告。如果不这样做，那些功能可能完全无法使用。
每当您不在Redux中存储组件状态更改时，该更改将从Redux更改堆栈中完全丢失，并且您的应用程序UI将与商店不同步。如果这对你不重要，那么问问自己为什么要使用Redux？没有它，您的应用程序将不那么复杂！
出于性能原因，您可能希望回退到this.setState()，以获取可以反复发送许多操作的任何内容。例如：每次用户键入密钥时，在Redux中存储输入字段的状态可能导致性能不佳。您可以通过将其视为事务来解决此问题：一旦用户操作“已提交”，则将最终状态保存在Redux中。
您的原始帖子提到Redux方式是如何“编写很多代码的地狱”。是的，但您可以使用抽象来处理常见模式，例如本地组件状态。