《深入React技术栈》学习笔记Ⅳ

一、缘起：为什么要有状态管理工具
在实践中，我们一般追求组件只负责渲染到来的数据，而不在组件中做异步数据请求，这样业务逻辑与数据请求耦合是不合理的。另外，由于 React 状态的单向流动，如果跨级传递数据的话会出现很多复杂的状态传递，这个时候把状态从组件中抽出来，由状态管理工具做请求，处理数据，组件只需要对拿到的数据做渲染，就非常干脆利落。

二、前世：聊聊 MVC 带来的方便与问题
MVC 有个特点是，Controll 层负责处理数据，Model 层负责存储数据，View 层负责渲染数据，View 层如果因为交互会发生数据的改变，则会传递到 Controll 层，由 Controll 写入 Model 中，而 Model 的变化则会直接通过 View 反应出来，这揭示了 MVC 中 View 和 Model 的关系：两者可以互相影响，在 Backbone 中，Model 甚至可以被直接修改，和监听，在大型的项目中，这种状态改变方向的混乱，当一个 Model 被修改可能会触发很多状态事件，最后就是状态的莫名改变，不知道为什么一个数据的变化会导致另一个数据或者 View 层的变化，虽然没经历过 Backbone，但是这种模式听起来就是觉得很混乱。

三、今生：Flux 的解决方案
Flux 的解决方案就是：数据和逻辑永远是单向流动的，Flux 由 view, state, dispatch, action 组成，要修改 store，必须 dispatch 一个 action，store 会有监听 action 的事件，当一个 action 触发，store会根据 action 的数据做数据逻辑修改。
Flux 对 action 做出了规范要求：每个 action 必须有 type，不能有 payload, error, meta 之外的其他字段。
实际上 Flux 中还有一个 Controll-View，复制将 store 中的数据渲染到 view 中。

1. dispatch 和 action
   dispatch 的实现中，我们只需要关心两个API：.register(callback)和.dispatch(action)。register用来注册一个监听器，dispatch 用来分发一个 action。

2. store
   store 负责保存数据和修改数据中的逻辑，同时调用 dispatch 的 register 方法将自己注册成为一个监听器，这样当我们 dispatch 一个 action 的时候，store 注册的监听器就会被调用，同时得到这个 action 作为参数。

3. controll-view
   controll-view 负责调用 store 暴露出来的 getter，获取其中的数据并设置为自己的 state，在 render 时将数据以 props 的形式传给子组件。

4. view
   就是 React。

5. actionCreator
   就是将 dispatch 调用一个 action 的操作封装起来，这样直接调用 actionCreator 就能直接 dispatch 一个 action。