Flux模式简析

2,349 阅读5分钟
  • flux 的核心思想是中心化控制,它让所有的请求与改变都只能通过 action 发出,统一 由 dispatcher 来分配。好处是 View 可以保持高度简洁,它不需要关心太多的逻辑,只需要关心传入的数据。中心化还控制了所有数据,发生问题时可以方便查询。
  • flux 缺点也很明显,层级太多,需要重复写太多的冗余代码。
  • Flux_GitHub地址

一个 Flux 应用包含四个部分:

  • Dispatcher,处理动作分发,维持 Store 之间的依赖关系
  • Store,负责存储数据和处理数据相关逻辑
  • Action,触发 Dispatcher
  • View,视图,负责显示用户界面

流程图

  • 通过上图可以看出来,Flux 的特点就是单向数据流:
    1. 用户在 View 层发起一个 Action 对象给 Dispatcher
    2. Dispatcher 接收到 Action 并要求 Store 做相应的更改
    3. Store 做出相对应更新,然后发出一个 change 事件
    4. View 接收到 change 事件后,更新页面

简单图示对比MVC

  • 基本的MVC数据流

  • 复杂的MVC数据流

  • 基本的Flux数据流

  • 复杂的Flux数据流

相比MVC模式,Flux多出了更多的箭头跟图标,但是有个关键性的差别是:所有的剪头都指向一个方向,在整个系统中形成一个闭环。


模式的演变

  • 与其说Flux是MVC模式的颠覆,不如说是对MVC模式的创新
    1. 传统的MVC模式中,View对Model直接修改的方式非常直截了当,适合小型web应用,然而一但web应用中存在多个Model,多个View,那么Model和View之间的决定关系就可能变得混乱,难以驾驭,并且这种模式阻碍了Model和View的组件化拆分。
    2. 而对比上面两个复杂模式下的对比图,我们发现MVC模式下真正的痛点在于: 缺少了一个和用户交互行为有关的action抽象
  • 从代码层面而言,flux无非就是一个常见的event dispatcher,其目的是要将以往MVC中各个View组件内的controller代码片断提取出来放到更加恰当的地方进行集中化管理,并从开发体验上实现了舒适清爽、容易驾驭的“单向流”模式,并且在这种调度模式下面,事情的变化变得清晰可预测。

Flux源码简析

"shut up and show me the code"

 这里主要分析Dispatcher文件代码

Dispatcher文件初始化

var invariant = require('invariant');
export type DispatchToken = string;
var _prefix = 'ID_';
class Dispatcher<TPayload> {
  _callbacks: {[key: DispatchToken]: (payload: TPayload) => void};
  _isDispatching: boolean;
  _isHandled: {[key: DispatchToken]: boolean};
  _isPending: {[key: DispatchToken]: boolean};
  _lastID: number;
  _pendingPayload: TPayload;

  constructor() {
    this._callbacks = {};
    this._isDispatching = false;
    this._isHandled = {};
    this._isPending = {};
    this._lastID = 1;
  }
  register(callback: (payload: TPayload) => void): DispatchToken {
    var id = _prefix + this._lastID++;
    this._callbacks[id] = callback;
    return id;
  }
  ...
}
  • 代码是截取过的,这里主要是注册一个DispatchToken函数,前缀'ID_'加上自增的++确保唯一(一个store对应多个id应该也是可行的)
    • callbacks,就是DispatchToken和函数回调的一个Dictionary。
    • isDispatching,体现当前Dispatcher是否处于dispatch状态。
    • isHandled,通过token去检测一个函数是否被处理过了。
    • isPending,通过token去检测一个函数是否被提交Dispatcher了。
    • lastID,最近一次被加入Dispatcher的函数体的UniqueID,即DispatchToken。
    • pendingPayload,需要传递给调用函数的参数。

dispatch方法

dispatch(payload: TPayload): void {
    invariant(
      !this._isDispatching,
      'Dispatch.dispatch(...): Cannot dispatch in the middle of a dispatch.'
    );
    this._startDispatching(payload);
    try {
        for(var id in this._callbacks) {
    if (this._isPending[id]) {
        continue;
    }
    this._invokeCallback(id);
}} finally {
    this._stopDispatching();
}}

isDispatching(): boolean {
    return this._isDispatching;
}

_invokeCallback(id: DispatchToken): void {
    this._isPending[id] = true;
    this._callbacks[id](this._pendingPayload);
    this._isHandled[id] = true;
}

_startDispatching(payload: TPayload): void {
for(var id in this._callbacks) {
    this._isPending[id] = false;
    this._isHandled[id] = false;
}
this._pendingPayload = payload;
this._isDispatching = true;
}

_stopDispatching(): void {
    delete this._pendingPayload;
    this._isDispatching = false;
}
  • 主要是判断函数是否处于pending状态,将非pending状态的callback通过_invokeCallback执行,所有执行完了以后,通过_stopDispatching恢复状态。
    1. _startDispatching函数的作用,是将所有注册的callback的状态都清空,并标记Dispatcher的状态进入dispatching
    2. _invokeCallback函数很简单,当真正调用callback之前将其状态设置为pending,执行完成之后设置为handled

waitFor方法

  waitFor(ids: Array<DispatchToken>): void {
    invariant(
      this._isDispatching,
      'Dispatcher.waitFor(...): Must be invoked while dispatching.'
    );
    for (var ii = 0; ii < ids.length; ii++) {
      var id = ids[ii];
      if (this._isPending[id]) {
        invariant(
          this._isHandled[id],
          'Dispatcher.waitFor(...): Circular dependency detected while ' +
          'waiting for `%s`.',
          id
        );
        continue;
      }
      invariant(
        this._callbacks[id],
        'Dispatcher.waitFor(...): `%s` does not map to a registered callback.',
        id
      );
      this._invokeCallback(id);
    }
  }
  • 简单的认为,dispatch方法对回调的遍历是简单、同步式的。当在执行callback过程中遇到waifFor方法时,对当前callback的调用就会中断,wairFor方法会根据声明的依赖重新确定遍历顺序,当所有依赖都被执行后,原先中止的callback才会继续执行。
  • ps:下面这段话来自于复制(权当参考)
    1. 首先是一个Invariant判断当前必须处于Dispatching状态。一开始比较难理解,简单来说就是,如果不处于Dispatching状态中,那么说明压根没有函数在执行,那你等谁呢?
    2. 然后该函数从DispatchToken的数组中进行遍历,如果遍历到的DispatchToken处于pending状态,就暂时跳过他。
    3. 但是,在这有个必要的循环以来的检查,试想如下情况,如果A函数以来B的Token, B函数依赖A的Token,就会造成“死锁”。所以,当一个函数依赖的对象处于pending,说明这个函数已经被开始执行了,但是如果同时该函数没有进入handled状态,说明该函数也被卡死了。
    4. 检查token对应的callback是否存在,调用这个token对应的函数。

  • ps: 这里面的部分图片以及说明来自于第三方,但是想不起来了😂