统一状态管理 + 单一资料流

我一开始在学 Vuex 的时候，觉得很难懂，不知道它是在做什麽的。当时的我，就想先追朔单一资料流的始祖(应该是吧？) flux

Flux

它提出了不少更新画面的理论与观念，之後的 Redux 和 Vuex 使用的专有名词，都和它的用词有相关性。

撰写本文时 flux 已进入维护模式，不建议使用了。

整体的模型长这样。

由於这是 facebook 出的 pattern 所以上面都会讲要和 React 整合。

这个图的出发点在 User Interactions 网页和使用者互动的时候，会呼叫 Action Creators ，在此处理非同步的 Web API 取得远端服务器上的资料。

经过中间的辗转，将资料储存在 Store。再经过 Change Events + Store Queries 将资料更新到画面上。

资料的旅行

Dispatcher

• 整个 application 唯一的一个 (singleton)
• Store 向 Dispatcher 注册通知变更
• Action 透过 Dispatcher 更新 Store

Store

• 每个 application 可拥有多个 store
• 资料中⼼
• 透过 action 呼叫 mutate 更改 store 的 data
• no public setter, only getter
• 资料改变发⽣在 'change' event

Action

• 定义内部 API
• 动作中心
• 任何与 application 的互动方式
• 语意化命名行为

View (图上是 ReactViews)

• Data 从 Store 拿出來显示
• View 必须订阅 store 的 change 事件
• Action 也是由View 与使⽤者户动而触发的

为什麽要单一资料流？

其实，只要宣告一个全域变数或物件，甚至做出 getter/setter 的抽象给物件使用，就足以管理这些全域的资料了，为什麽还要「单一资料流」呢？

其实，最主要的原因在於方便 debug ，如果一切都顺利，是不是单资料流似乎不是这麽重要，但是万一出错了，是不是单一资料流就会是一件很重要的事情，它会将很多连续执行的资料设定，弄成由 dispacher 处理，一次处理一个。并且可以透过开发者工具看见。

透过一步一步的查询，可以看得见哪一次赋值不如预期，所以造成问题。

没有单一资料流的 AngularJS

在 AngularJS 中就有出现广播的方式，每次呼叫都会通知程序码呼叫它注册好的 callback，而 dispatcher 其实是一种广播系统，它限缩在一个可控的状况。让各处都可以呼叫注册好的 callback。

虽然语法相同，但是用法不同，就会造成灾难。
由於是广播系统，所以有些人的用法就是直接从这个 view 呼叫另一个 view 的 method ，为的是原本更新资料没有更新到的画面，可以强制更新。

但也许更新资料本身并没有遵守 immutable 的原则，所以才会出问题，而不需要呼叫强制更新。造成不必要的耦合。

AngularJS 也有 service 来处理共用的程序码。但是正因为在那个时候也许单一资料流还不是显学，所以没有把这个东西做成一个套件。所以用 service 只是用来共用的人，就很难管理修改资料的前後顺序与除错的问题。

後来的 Vuex

使用了 dispatch 来呼叫 action
使用了 commit 来呼叫 mutation
使用了 getters 来呼叫 getters
使用了 state 来呼叫 state

接下来会花几天的时间，慢慢的介绍，我自己如何看待 vuex 以及如何使用它。