章节 0 - 简介
首先，为什么会有这个教程呢？
在我尝试学习 Redux 的时候，我发现之前阅读过的一些文章加上个人的经验，让我对 flux 产生了一些误解。
当然，我不是说那些关于 flux 的文章写得不好，只是我没能正确地领会其中的概念。到头来，我只是对着各种 flux 框架（Reflux、Flummox、FB Flux）的文档照猫画虎，并试着把它们和之前了解到的理论概念联系起来 （actions / actions creators、 store、 dispatcher）。
等我用了 Redux 之后，我才发现原来 flux 比我想象的要简单很多。
这些都归功于 Redux 通过优良的设计减少了样板代码，而其它框架则是为了减少样板代码却又引入了很多新的代码。
我现在觉得用通过 Redux 来学习 flux 比通过其他框架高效得多。
这就是为什么我想分享给大家这个教程，通过关注 Redux 的用法来理解 flux 的概念。
你可能已经看过这张著名的 flux 的单向数据流图了。
_________ ____________ ___________
| | | | | |
| Action |------------▶| Dispatcher |------------▶| callbacks |
|_________| |____________| |___________|
▲ |
| |
| |
_________ ____|_____ ____▼____
| |◀----| Action | | |
| Web API | | Creators | | Store |
|_________|----▶|__________| |_________|
▲ |
| |
____|________ ____________ ____▼____
| User | | React | | Change |
| interactions |◀--------| Views |◀-------------| events |
|______________| |___________| |_________|在这个教程里，我们会一步步地向你介绍上图里的各个概念。我们会把这些概念分成单独的章节来介绍它们存在的意义和作用。在最后，当我们理解了每一个概念后，我们会发现这张图真是意义深远啊！
在我们开始之前，我们先聊下一 flux 存在的意义以及我们为什么需要它。
假设我们正在构建一个网站应用，那么这个网站应用会由什么组成呢？
- 模板/HTML = View
- 填充视图的数据 = Model
- 获取数据、将所有视图组装在一起、响应用户事件、
数据操作等等的逻辑 = Controller
这是我们熟知的非常典型的 MVC，但它和 flux 的概念其实是很像的，只是在某些表述上有些小小的不同：
- Model 看起来像 Store
- 用户事件、数据操作以及它们的处理程序看起来像
action creators -> action -> dispatcher -> callback - View 看起来像 React view (或者其它类似的概念)
所以，flux 就只是一个新名词么？不全是，但是新名词是很重要的，因为通过引入这些新术语我们可以更准确地表述各种专业术语。
举一个例子，获取数据是一个 action，一个点击是一个 action，一个 input 变化也是一个 action 等等。我们都已经习惯了从我们的应用里分发 action，只是以不同的方式称呼它们。 不同于直接修改 Model 和 View，Flux 确保所有 action 首先通过一个 dispatcher，然后再是 store，最后通知所有的 store 监听器。
为了弄清楚 MVC 和 flux 的不同，我们举一个典型的 MVC 应用的用例：
一个典型的 MVC 应用的流程大致上是这样的：
- 用户点击按钮 A
- 点击按钮 A 的处理程序触发 Model A 的改变
- Model A 的改变处理程序触发 Model B 的改变
- Model B 的改变处理程序触发 View B 的改变并重新渲染自身
在这样的一个环境里，当应用出错的时候快速地定位 bug 来源是一件非常困难的事情。
这是因为每个 View 可以监视任何的 Model，并且每个 Model 可以监视其它所有 Model，所以数据会从四面八方涌来，并且被许多源（view 或者 model）改变。
当我们用 flux 以及它的单向数据流的时候，上面的例子就会变成这样子：
- 用户点击按钮 A
- 点击按钮A的处理程序会触发一个被分发的 action，并改变 Store A
- 因为其它的 Store 也被这个 action 通知了，所以 Store B 也会对相同的 action 做出反应
- View B 因为 Store A 和 Store B 的改变而收到通知，并重新渲染
来看一下我们是如何避免 Store A 和 Store B 直接相关联的。Store 只能被 action 修改，别无他选。
并且当所有 Store 响应了 action 后，View 才会最终更新。由此可见，数据总是沿着一个方向进行流动：
action -> store -> view -> action -> store -> view -> action -> ...
上面我们首先从 action 开始我们的用例，下面让我们同样以 action 和 action creator 来开始我们的教程。