假设我有一个简单的切换：
当我单击按钮时，颜色组件在红色和蓝色之间变化
我可能会通过做这样的事情来达到这个结果。
索引.js
Button: onClick={()=>{dispatch(changeColor())}}
Color: this.props.color ? blue : red
容器.js
connect(mapStateToProps)(indexPage)
action_creator.js
function changeColor(){
return {type: 'CHANGE_COLOR'}
}
减速器.js
switch(){
case 'CHANGE_COLOR':
return {color: true}
但这是一大堆代码，我可以在 5 秒内用 jQuery、一些类和一些 css 来实现......
所以我想我真正要问的是，我在这里做错了什么？
Redux 主要用于“应用程序状态”。也就是说，任何与您的应用程序逻辑相关的东西。建立在它之上的视图是该状态的反映，但不必专门使用该状态容器来完成它所做的一切。
只需问以下问题：此状态对应用程序的其余部分重要吗？应用程序的其他部分是否会根据该状态表现不同？在许多小情况下，情况并非如此。拿一个下拉菜单：它打开或关闭的事实可能不会对应用程序的其他部分产生影响。因此，将其连接到您的商店可能有点矫枉过正。这当然是一个有效的选择，但并没有真正为您带来任何好处。你最好使用this.state它并结束它。
在您的特定示例中，切换按钮的颜色是否对应用程序的其他部分产生任何影响？如果它是应用程序主要部分的某种全局开/关切换，那么它绝对属于商店。但是，如果您只是在单击按钮时切换按钮颜色，则可以保留本地定义的颜色状态。单击按钮的动作可能有其他需要动作分派的效果，但这与它应该是什么颜色的简单问题是分开的。
一般来说，尽量让你的应用程序状态尽可能小。你不必把所有东西都塞进去。在必要时这样做，或者在那里保留一些东西很有意义。或者，如果使用开发工具让您的生活更轻松。但不要过分强调它的重要性。
Redux FAQ：Organizing State
这部分 redux 官方文档很好地回答了你的问题。
使用本地组件状态很好。作为开发人员，您的工作是确定构成您的应用程序的状态类型，以及每个状态应位于何处。找到一个适合你的平衡点，然后坚持下去。
确定应该将哪种数据放入 Redux 的一些常见经验法则：
- 应用程序的其他部分是否关心这些数据？
- 您是否需要能够基于这些原始数据创建进一步的派生数据？
- 是否使用相同的数据来驱动多个组件？
- 能够将这种状态恢复到给定的时间点（即时间旅行调试）对您来说是否有value？
- 您是否要缓存数据（即，如果它已经存在，则使用它的状态而不是重新请求它）？
为了突出@AR7 提供的重要链接，并且因为该链接移动了一段时间：
将 React 用于对全局应用程序无关紧要且不会以复杂方式变异的临时状态。例如，某个 UI 元素中的切换、表单输入状态。将 Redux 用于全局重要或以复杂方式变异的状态。例如，缓存的用户或帖子草稿。
有时你会想要从 Redux 状态移动到 React 状态（当在 Redux 中存储一些东西变得尴尬时）或相反（当更多组件需要访问一些曾经是本地的状态时）。
经验法则是：做任何不那么尴尬的事情。
丹·阿布拉莫夫：https : //github.com/reactjs/redux/issues/1287#issuecomment-175351978
这就是 Redux 的问题，开发人员过度设计状态设计，这总是将可能相当简单的应用程序变成复杂的结构。
Redux 对我来说是一种react架构，应该在实施之前进行良好的计划和设计。
https://kentcdodds.com/blog/application-state-management-with-react/ “redux 如此成功的原因之一是 react-redux 解决了 Prop-Drilling 问题。通过简单地将组件传递给一些神奇的连接函数，您可以在树的不同部分共享数据，这一事实非常棒。它对减速器/动作创建者/等的使用。也很棒，但我相信 redux 无处不在是因为它解决了开发人员的 Prop-Drilling 痛点。
这就是我只在一个项目中使用过 redux 的原因：我一直看到开发人员将他们所有的状态都放到了 redux 中。不仅是全局应用程序状态，还有本地状态。这会导致很多问题，其中最重要的是，当您维护任何状态交互时，它涉及与减速器、动作创建者/类型和调度调用的交互，最终导致必须打开许多文件并进行跟踪通过头脑中的代码找出正在发生的事情以及它对代码库的其余部分有什么影响。“”
是的，努力将所有组件状态存储在 Redux 中是值得的。如果这样做，您将受益于 Redux 的许多功能，例如时间旅行调试和可重播的错误报告。如果不这样做，这些功能可能完全无法使用。
任何时候您不在Redux 中存储组件状态更改，该更改都会从 Redux 更改堆栈中完全丢失，并且您的应用程序 UI 将与存储不同步。如果这对你来说并不重要，那么问问自己为什么要使用 Redux？没有它，您的应用程序将不那么复杂！
出于性能原因，您可能希望回退到this.setState()任何会重复调度许多操作的东西。例如：每次用户键入一个键时，将输入字段的状态存储在 Redux 中可能会导致性能不佳。您可以通过将其视为事务来解决此问题：一旦“提交”用户操作，将最终状态保存在 Redux 中。
您的原始帖子提到了 Redux 方式是如何“编写大量代码的地狱”。是的，但您可以对常见模式（例如本地组件状态）使用抽象。