当我们编写应用程序时，我们需要管理应用程序的状态。如果需要在组件之间共享状态，React可以在组件内部本地管理状态，我们可以使用prop或回调。

但是随着应用程序的增长，管理状态和状态转换变得很困难，为了调试应用程序，需要正确跟踪状态和状态转换。

Redux是JavaScript应用程序的可预测状态容器，用于管理状态和状态转换，并经常与React，

下图可以解释redux的概念。

当用户与组件进行交互时用户触发一个动作，并调度一个动作来存储时，存储中的化简器将接受该动作并更新应用程序的状态，并在存储中进行更新时将其存储在应用程序范围的不可变全局变量中订阅该状态的相应视图组件将得到更新。

由于状态是全局管理的，因此可以更轻松地进行维护。

这就是redux的工作方式。从任何组件或视图调度动作。动作必须具有“类型”属性，并且可以是保存发生的动作信息的任何属性。实际传递的数据可能与不同的reducer有关，因此同一对象将传递给不同的reducer。每个reducer提取/贡献其状态部分/贡献。然后合并输出并形成新状态，并通知必须为状态更改事件订阅的组件。

在上面的示例中，棕色具有所有3个分量RGB。每个还原剂都接收相同的棕色，并且将其对颜色的贡献分开。

我发现，添加到Redux的应用程序/堆栈理想的路径是要等到之后你/应用/团队都感到痛苦，它解决了。一旦开始看到props由多个层次的组件建立和传递的漫长链条，或者发现您正在编排复杂的状态操作/读取，这可能表明您的应用可能会受益于Redux等的引入。

我建议您使用已经使用“ just React”构建的应用程序，并查看Redux可能如何适合其中。看看您是否可以一次抽出一个状态或一组“动作”来优雅地介绍它。对其进行重构，而不必大为改写您的应用程序。如果您仍然看不到它可以在何处增加价值，那么这可能表明您的应用程序不够大或不够复杂，无法在React之上使用Redux之类的东西。

如果您还没有看过它，Dan（上面回答）会提供一个很棒的短片系列，从根本上讲解Redux。我强烈建议您花一些时间吸收其中的一些内容：https : //egghead.io/series/getting-started-with-redux

Redux也有一些很棒的文档。尤其要解释很多“为什么”，例如http://redux.js.org/docs/introduction/ThreePrinciples.html

使用过Redux并亲自发现它很麻烦之后，我发现将对象作为道具传递给我的组件是一种更容易维护状态的方法。更不用说这是对函数的引用以调用其他组件的简单方法。它可以解决在React中组件之间传递消息的许多麻烦问题，因此这是一对二的。

React是一个UI框架，负责响应“真理源”（通常被描述为某个组件“拥有”的状态）来更新UI。在React中的思考很好地描述了React状态所有权的概念，我强烈建议您仔细研究一下。

当状态是分层的并且或多或少与组件结构匹配时，此状态所有权模型可以很好地工作。这样，状态就可以“分散”到许多组件中，并且该应用程序易于理解。

但是，有时应用程序的较远部分希望能够访问相同的状态，例如，如果您缓存获取的数据并希望同时在各处一致地更新它。在这种情况下，如果您遵循React模型，您将在组件树的顶部得到一堆非常大的组件，这些组件将无数个prop向下传递给一些不使用它们的中间组件，只是为了到达一些实际上关心该数据的叶子组件。

When you find yourself in this situation, you can (but don’t have to) use Redux to “extract” this state management logic from the top-level components into separate functions called “reducers”, and “connect” the leaf components that care about that state directly to it instead of passing the props through the whole app. If you don’t have this problem yet, you probably don’t need Redux.

最后，请注意，Redux并不是解决此问题的最终解决方案。还有许多其他方法可以在React组件之外管理您的本地状态-例如，一些不喜欢Redux的人对MobX感到满意。我建议您首先对React状态模型有一个深刻的了解，然后独立评估不同的解决方案，并与它们一起构建小型应用程序，以了解它们的优缺点。

（此答案的灵感来自于Pete Hunt的反应方法指南，我建议您也阅读它。）