原文链接:When do I know I’m ready for Redux? ，需要科学上网。
最近在学习 React 里面的 Redux ，正好在 Google 上面找到这文章，觉得里面的动态图很有意思，就起了翻译的念头。
PS:阅读文章之前需要理解什么是 React 的 props 和 state ，还有就是我并没有全部翻译，只是翻译了自己感兴趣的部分。
什么是Redux？
Redux 是一个专注于应用状态管理的库， 它是 React 应用程序中使用的常用的一个工具库。
我们为什么要使用 Redux
过早优化是万恶之源。—唐纳德·克努特
这是我们在构建程序是一个准则，这也是为什么我们一开始在构建最新的 React 应用程序时，我们选择使用 React 本地组件状态开始管理我们的应用程序状态。
新的 React 应用程序前几周运行得非常好，但是随着版本的迭代，我们开始发现程序管理的难度在不断上升！
Day1
我们开始使用 React 本地组件状态来管理应用程序。
React 使用单向数据流，这意味着父组件把自身的状态作为属性传递给子组件。
Day5
我们添加了更多的功能，一些组件需要共享他们的状态(state)，但是它们与其他组件并非父组件和子组件的关系。
不过没关系，我们通过了“提升状态” 来解决了这个问题。
这意味着我们将状态（和改变这个状态的函数）提升到最接近的父组件（Container Component）。
我们将这些函数绑定到容器组件，并将它们作为属性向下传递。
这意味着子组件可以触发其父组件中的状态更改，这将更新树中的所有其他组件。
Day20
然而，随着添加了更多的功能和组件，我们发现组件之间的互动实在太多了，为了管理好组件之间的 state ，导致了某些组件的代码变得非常臃肿。
我们只能看着我们的代码库越来越像一碗意大利面，代码混乱之极。
正如你所看到的，状态在应用程序中更新和分散的方式变得越来越复杂。
1. 一个组件需要共享它的状态给好几个组件
2. 一个组件的状态改变发生的属性(props)传递，需要横过好几个组件
3. 程序越来越难进行debug
如果开始遇到上述某些问题，就意味着可能应该使用 Redux 了。
这种组件间的通讯地狱，管理起来可不仅仅是痛苦。。。。
Rudex 是如何改善困境的？
由于个人觉得阮一峰老师关于 Redux 入门教程 里面的概念讲述更具体形象，所以这里我套用了阮一峰老师的部分文章内容
首先，并非所有的 React 应用程序都需要使用 Redux 的。
如果你不确定是否使用 Rudex ，那么你就是不需要的。
如果你遇到了无法解决的难题(比方说我们刚才遇到的难题)，那么 Rudex 可能就是你需要的东西。
Redux 的设计思想很简单，就两句话:
1. 整个系统是一个状态机，视图与状态是一一对应的
2. 所有的状态，保存在一个对象里面
这里简单介绍一下 Rudex 的概念：
Store
Store 就是保存应用组件状态(state)数据的地方，你可以把它看成一个容器。整个应用只能有一个 Store。
State
Store 对象包含所有数据。如果想得到某个时点的数据，就要对 Store 生成快照。这种时点的数据集合，就叫做 State 。
当前时刻的 State ，可以通过 store.getState() 拿到。
Redux 规定， 一个 State 对应一个 View 。只要 State 相同，View 就相同。
你知道 State，就知道 View 是什么样，反之亦然。
Action
State 的变化，会导致 View 的变化。但是，用户接触不到 State，只能接触到 View 。
所以，State 的变化必须是 View 导致的。
而 Action 就是 View 发出的通知，表示 State 应该要发生变化了。
Action 是一个对象，其中的 type 属性是必须的，表示 Action 的名称，其他属性可以自由设置。
Reducer
Store 收到 Action 以后，必须给出一个新的 State，这样 View 才会发生变化。
这种 State 的计算过程就叫做 Reducer。
Reducer 是一个函数，它接受 Action 和当前 State 作为参数，返回一个新的 State。
也由于 Reducer 是纯函数，就可以保证同样的 State ，必定得到同样的 View ，也就可以保证页面的刷新。
使用 Redux 我们每派发一个动作，这会触发我们的 Reducer 功能，从而更新我们的 Store ，从而让 View 实现刷新。现在，我们的应用程序看起来就是下面这个样子了：
