一、总结
一句话总结：
React 只是 DOM 的一个抽象层，并不是 Web 应用的完整解决方案。有两个方面，它没涉及。【代码结构】、【组件之间的通信】。对于大型的复杂应用来说，这两方面恰恰是最关键的。因此，【只用 React 没法写大型应用】。
为了解决这个问题，2014年 Facebook 提出了 【Flux 架构】的概念，引发了很多的实现。2015年，Redux 出现，将 【Flux 与函数式编程】结合一起，很短时间内就成为了最热门的前端架构。
"【只有遇到 React 实在解决不了的问题，你才需要 Redux】 。"简单说，如果你的UI层非常简单，没有很多互动，Redux 就是不必要的，用了【反而增加复杂性】。
二、Redux基本介绍
React 只是 DOM 的一个抽象层，并不是 Web 应用的完整解决方案。有两个方面，它没涉及。
- 代码结构
- 组件之间的通信
对于大型的复杂应用来说，这两方面恰恰是最关键的。因此，只用 React 没法写大型应用。
为了解决这个问题，2014年 Facebook 提出了 Flux 架构的概念，引发了很多的实现。2015年，Redux 出现，将 Flux 与函数式编程结合一起，很短时间内就成为了最热门的前端架构。
本文详细介绍 Redux 架构，由于内容较多，全文分成三个部分。今天是第一部分，介绍基本概念和用法。
零、你可能不需要 Redux
首先明确一点，Redux 是一个有用的架构，但不是非用不可。事实上，大多数情况，你可以不用它，只用 React 就够了。
曾经有人说过这样一句话。
"如果你不知道是否需要 Redux，那就是不需要它。"
Redux 的创造者 Dan Abramov 又补充了一句。
"只有遇到 React 实在解决不了的问题，你才需要 Redux 。"
简单说，如果你的UI层非常简单，没有很多互动，Redux 就是不必要的，用了反而增加复杂性。
- 用户的使用方式非常简单
- 用户之间没有协作
- 不需要与服务器大量交互，也没有使用 WebSocket
- 视图层（View）只从单一来源获取数据
上面这些情况，都不需要使用 Redux。
- 用户的使用方式复杂
- 不同身份的用户有不同的使用方式（比如普通用户和管理员）
- 多个用户之间可以协作
- 与服务器大量交互，或者使用了WebSocket
- View要从多个来源获取数据
上面这些情况才是 Redux 的适用场景：多交互、多数据源。
从组件角度看，如果你的应用有以下场景，可以考虑使用 Redux。
- 某个组件的状态，需要共享
- 某个状态需要在任何地方都可以拿到
- 一个组件需要改变全局状态
- 一个组件需要改变另一个组件的状态
发生上面情况时，如果不使用 Redux 或者其他状态管理工具，不按照一定规律处理状态的读写，代码很快就会变成一团乱麻。你需要一种机制，可以在同一个地方查询状态、改变状态、传播状态的变化。
总之，不要把 Redux 当作万灵丹，如果你的应用没那么复杂，就没必要用它。另一方面，Redux 只是 Web 架构的一种解决方案，也可以选择其他方案。
