React是一个UI框架，负责更新UI以响应“真实来源”，通常被描述为某个组件“拥有”的状态。Thinking in React很好地描述了React状态所有权的概念，我强烈建议你仔细阅读。
当状态是分层的并且或多或少与组件结构相匹配时，这种状态所有权模型工作得很好。通过这种方式，状态可以“分散”到许多组件中，并且应用程序很容易理解。
然而，有时应用程序的远程部分希望访问相同的状态，例如，如果您缓存获取的数据并希望同时在任何地方一致地更新它。在这种情况下，如果你遵循React模型，你最终会在组件树的顶部看到一堆非常大的组件，它们通过一些不使用它们的中间组件传递无数的prop，只是为了到达一些真正关心这些数据的叶子组件。
当你发现自己处于这种情况时，你可以（但不必）使用Redux将这种状态管理逻辑从顶层组件中“提取”到称为“reducers”的单独函数中，并将关心该状态的叶子组件直接“连接”到它，而不是通过整个应用传递props。如果你还没有遇到这个问题，你可能不需要Redux。
最后，请注意Redux并不是这个问题的最终解决方案。在React组件之外，还有许多其他方法可以管理本地状态-例如，一些不喜欢Redux的人对MobX很满意。我建议你首先对React状态模型有一个深刻的理解，然后独立地评估不同的解决方案，并使用它们构建小应用程序，以了解它们的优点和缺点。
(This答案的灵感来自Pete Hunt的react-howto指南，我建议你也读一读。

我发现，将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。希望这能消除你的疑虑。
--------------------------- REDUX教程----------
操作-操作是将数据从应用程序发送到存储的信息负载。他们是商店的唯一信息来源。您只能使用store.dispatch（）发送它们。

Example-
const  ADD_TODO = 'ADD_TODO'

{
   type:ADD_TODO,
   text: 'Build my first redux app'
}

action是简单的JavaScript对象。操作必须有一个[ type ]属性，用于指示正在执行的操作的类型。类型应定义为字符串常量。
动作创建器--动作创建器正是创建动作的功能很容易混淆术语-动作和动作创建器。在redux action中，creator返回一个action。

function addToDo(text) {
   return {
    type: ADD_TODO,
    text    
   }
}

将结果传递给dispatch（）函数。

1. dispatch（addToDo（text））;
2. dispatch（completeToDo（index））
   或者，您可以创建自动分派的绑定操作创建器。

cosnt boundAddTodO = text => dispatch(addToDo(text));

现在你可以直接叫它

boundaddTodO(text);

dispatch（）函数n可以直接从store.dispatch（）访问。但是我们使用helper connect（）方法访问它。

js.js....

行动.....

exports cosnt ADD_TODO = 'ADD_TODO';
exports cosnt TOGGLE_TODO = 'TOGGLE_TODO'

Actions创建者

导出函数addToDO（text）{ return { type：ADD_TODO，text } }
减压器.....
Reducer指定应用程序状态如何响应发送到存储的操作而更改。

设计状态形状

在redux中，所有的应用程序状态都存储在一个对象中。您必须存储一些数据以及一些状态。
{验证筛选器：'SHOW_ALL'，todos：[ { text：'考虑使用redux'，已完成：true }，{ text：'将所有状态保留在单个树中' } ] }
处理操作-还原器是纯函数，它接受先前的状态和操作，并返回新的状态。
（previousState，action）=> newState
我们将从指定初始状态开始。Redux将第一次以未定义的状态调用我们的reducer。这是我们返回应用状态的机会

import  { visiblilityFilters } from './actions';
const initialState = {
    visibilityFilter: VisibilityFilters.SHOW_ALL,
    todo: []
}

function todoApp(state, action){
    if(typeof state == 'undefined'){
        return initialState;
    }

    // dont handle other cases as of now.
    return state;
}

你可以用ES6的方式来处理JS

function todoApp(state = initialState, action) {
  switch (action.type) {
    case SET_VISIBILITY_FILTER:
      return Object.assign({}, state, {
        visibilityFilter: action.filter
      })
    default:
      return state
  }
}

.................................储存...
商店是一个将他们聚集在一起的物体。本店有以下责任
1.保持应用状态
1.允许通过getState（）访问状态
1.允许通过dispatch（）更新状态
1.通过订阅器注册listerneres（listener）
注意：使用combineReducers（）将多个reducer合并为一个。
const store = new Store（todoapp）;//todoapp是reducer

这就是Redux的工作原理。从任何组件或视图分派操作。Action必须有“type”属性，可以是任何保存动作发生信息的属性。动作中传递的数据可能与不同的reducer相关，因此相同的对象会传递给不同的reducer。每个reducer都将其部分/贡献提交给国家。然后合并输出并形成新的状态，并且必须订阅状态更改事件的组件得到通知。
在上面的例子中，棕色有所有3个分量RGB。每个reducer接收相同的棕色，并将其对颜色的贡献分离出来。

首先，如果你不需要Redux，你不需要将它添加到你的应用程序中！简单，所以如果你根本不需要它，不要强迫自己在项目中包含它！但这并不意味着Redux不好，它在大型应用程序中真的很有帮助，所以请继续阅读。
Redux是React应用程序的状态管理，把Redux想象成一个本地存储，它可以跟踪你的状态，你可以在任何页面和路由中访问你想要的状态，同样与Flux相比，你只有一个存储，意味着一个真实的来源。
看看这张图片，首先了解Redux的功能：

Redux也是这样介绍自己的：

Redux是JavaScript应用的可预测状态容器。

它可以帮助您编写行为一致的应用程序，在不同的环境（客户端，服务器和本机）中运行，并且易于测试。最重要的是，它提供了一个很好的开发人员体验，例如与时间旅行调试器相结合的实时代码编辑。
您可以将Redux与React或任何其他视图库一起使用。它很小（2kB，包括依赖项）。
同样根据文档，Redux有三个原则：

1.单一真相来源
2.状态为只读
3.纯函数修改

所以基本上，当你需要一个单一的商店来跟踪你喜欢在你的应用程序中的任何东西，那么Redux是方便的，你可以在你的应用程序中的任何地方访问它，在任何路线。使用store.getState();
同样使用中间件Redux，你可以更好地管理状态，在Redux的官方页面上有一个方便的组件和中间件列表！
简单来说，如果你的应用程序很大，有很多组件，状态和路由，试着从一开始就实现Redux！它会帮助你在路上肯定！

当我们编写应用程序时，我们需要管理应用程序的状态。React在组件内部本地管理状态，如果我们需要在组件之间共享状态，我们可以使用props或回调。
但是随着应用程序的增长，管理状态和状态转换变得越来越困难，为了调试应用程序，需要正确地跟踪状态和状态转换。
Redux是JavaScript应用程序的可预测状态容器，用于管理状态和状态转换，通常与React一起使用，
redux的概念可以在下面的图片中解释。

当用户触发一个动作时，当用户与组件交互时，一个动作被调度到store，然后store中的reducer接受该动作并更新应用程序的状态，并存储在应用程序范围内的不可变全局变量中，当store中有更新时，订阅该状态的相应视图组件将得到更新。
由于状态是全局管理的，并且使用redux更容易维护。

在使用Redux之后，我个人发现它很麻烦，我发现将对象作为 prop 传递给我的组件可以是一种更容易的维护状态的方法。更不用说它是一种简单的方法来引用函数以在其他组件中调用。它可以解决React中组件之间传递消息的许多繁琐问题，所以它是一个二合一。

几篇文章似乎回答了这个问题：

TLDR Dan Abramov：

如果你的数据永远不会改变，你就不需要Redux。它的全部意义在于管理变化。

TSWM Mark Erikson：

在Redux的例子中，它是作为Flux架构的一个实现而发明的，而Flux架构的创建是为了处理人们在基于事件触发器的状态管理中发现的限制。
所以我设置了user.firstName，它触发了一个“change firstName”事件，其他一些代码正在监听它，它触发了另一个事件.接下来，你知道，你在一个大的同步调用堆栈下面有15个事件，你不知道为什么会发生这种情况。这就是Flux被发明来解决的问题，而Redux基本上完善了这种特殊的方法。
现在，由于Redux从一开始就使用了老式的React Context API，在React应用中使用Redux也碰巧有点意外地解决了另一个常见问题，那就是我的应用的许多不同部分需要同时使用相同的状态，我通常必须将该状态提升到根应用程序组件，以便许多组件共享数据。但是如果我这样做，那么我就必须进行prop-drill，并将数据作为props通过组件树的每一层，这是一个皇家的痛苦。

在React 16.3中，React推出了一个新的，改进的Context API。Context的唯一目的是充当一种依赖注入机制，作用于子树的某个部分，在那里你说“这里有一个值”，该组件子树的任何部分都可以请求读取该值。这就是它的全部功能。
**所以，如果你在Redux中唯一需要做的事情就是避免在15个组件级别中传递数据作为props-那么，这就是Context被发明的目的。

因此，如果这就是您所需要的，那么您不需要添加Redux来添加该功能;使用Context代替。