React 可视化开发工具 Shadow Widget 非正经入门（之四：flux、mvc、mvvm

摘要：是分发器，是数据与逻辑处理器，会在注册针对各个命令字的响应回调函数。当按如下方式触发回调时，回调函数具备事件的特性。

本系列博文从 Shadow Widget 作者的视角，解释该框架的设计要点。本篇解释 Shadow Widget 在 MVC、MVVM、Flux 框架之间如何做选择。

Facebook 官方为 React 提出了 flux 框架，也自己实现了一个 flux.js，尽管这个库设计得很差劲，但所有第三方为 React 开发的单向数据流方案，起点都是该库官方所提的 Flux concepts，下面是经典结构图：

Action 可简单理解为指令（或命令），由命令字 type 与命令参数 data（或称 payload）组成。Dispatcher 是分发器，Store 是数据与逻辑处理器，Store 会在 Dispatcher 注册针对各个命令字的响应回调函数。View 就是 React Component，View 常使用 Store 中的数据并订阅 Store 发生变化来刷新自身显示。

几个部件之间数据单向流动，如下：

  Action -> Dispatcher -> Store -> View

形成单向流动的原理较简单，大致这样，Store 在 Dispatch 注册的回调函数，由 Action 触发，Dispatcher 解析命令字，找出相应回调用函数实现调用即可。当 Dispatcher 按如下方式触发回调时，回调函数具备事件的特性。

  setTimeout( function() {
    callback();
  },0);

如果立即调用 callback，那只是回调，如果延时 0 秒会让 callback 在下个周期被调用，就成事件了，单向数据流因此得到保证。

当然，上面介绍非常简略，把核心机制讲明白，reflux、redux 让注册回调变事件也都用这个机制。当然，事件化回调的处理过程可能很复杂，比如 Dispatcher 还提供 waitFor() 等待一项或多项 Action 的接口，我们略去不细讲。

React 实现的虚拟 DOM 部分（即核心库 react.js 与 react-dom.js）是 MVC 中的 "V"，其 MVC 框架图如下：

当你只使用 React 的核心库，未使用 reflux、redux 等单向数据流机制时，所用的 MVC 就是上图样子。如何构造 Controller 与 Model 是自由的，甚至你想将它改造成 MVVM 也是自由的，毕竟 React 的核心库只提供虚拟 DOM 映射，与 HTML 原生的 DOM 一起提供 "View"。后面我们真的要介绍怎么改成 MVVM。

Flux、MVC、MVVM 这三者是对等的架构，我们不能直接将 Flux 框架往 MVC 上套。

在 React 中使用 MVC 主要缺陷是：当应用规模变大，M, V, C 之间依赖关系会变复杂。下图还不算太复杂，只用到 2 个 Module。

React 虚拟 DOM 对真实 DOM 做了一次抽像，附加 props、state 等概念，再加上异步时序干扰，原先还勉强玩得转的 MVC，已变得很不好用，开发、调试、定位问题都变困难了。

引入 Flux 能有针对性的缓解上述困难。其一，用单数据流向串接各 View，让与 Model 交互的那个 View（也称 Controller View）承担设计复杂性，其它 View 只做简单工作，如展示界面、简单响应鼠标点击等操作。

其二，用 Action 与 Dispatcher 简化 Controller，不弄那么多 Controller，归总到一个 Dispatcher。其三，采用 Functional Reactive Programming 方法构造响应式的单向数据流机制，以此应对异步时序问题。

React 生态链中有多种 Flux 实现，他们本质一样，表面差别不算大，通常几句话就能概括。reflux 采用多 store 方案，把用于集中分发的 Dispatcher 简化掉了，redux 采用单 store 方案，把分发 Action 后的处理分解给众多 Reducer 函数，也就是说，上图多个 Store 的功能，用 "单 Store + 众多 Reducer 函数" 替换。

Redux 最大优点是实施彻底函数式编程，最大缺点也是彻底函数式。它本身并未简化设计复杂性，只是转移复杂性，但按官方原生的 Flux 概念，我们是按对象方式理解一个个 Store 的，在设计时，处理 Store 与 View，以及与 Action 之间关系时，都按对象方式去思考的，现在把复杂性转移到众多 reducer 函数上，函数式思维不利于设计分解（相对对象化思维而言）。

Redux 之所以能盛行，与 React 自身限制有关。React 的虚拟 DOM 树限制数据单向（向下）传递，跨节点读取属性极不方便，如果我们把所有服务于 render 的 state 数据，独立到节点之外的全局函数（reducer）中去组装呢？所有用到的 state 串一起，形成一个大的全局变量（就是单 Store），reducer 函数想怎么读就怎么读。这个方案以大幅度函数式改造为代价，来突破 React 的限制。

Shadow Widget 做的正相反，尝试维持对象化思维习惯，把 Store 与 ViewModel 合一（后面还有详细说明）以便减轻思考负担；通过建立 Widget 树，用 this.componentOf() 快速检索相关节点，以求方便的存取属性；再设计 duals 双源属性，建立一套能自动识别数据变化，并驱动单向数据流的机制。

我们研究一下 Controller View 与 Store 对接及与下级 View 的连接关系，取上图局部，放大讲解，如下：

当 Store 中有数据更新，通知 Controller View 更新界面，Controller View 就从 Store 读得 state 数据，来更新自己的 state。而自身 state 变化将触发下级 View 联动更新，变化的信息在各子级借助 props 属性实现传递。

为下文讲解作准备，这里我们先拎一拎 Store 该具备的特性：

要提供事件通知功能，当 Store 中的 state 数据有变化，通知 Controller View 刷新界面。

对 Controller View 暴露 state 数据，有两种设计可选，一是让事件通知中带 state 数据，二是事件通知不带数据，要由 Controller View 主动到 Store 查询。结合 FRP 编程特点，第二个设计更好，如果数据连续多次更新，从 Store 读数据应合并为一次，取最新值。

何时通知 Controller View 刷新可能比较复杂，涉及条件组合，比如要 Action A 与 Action B 都发生后，才能触发事件通知。

我们换一个角度看 flux 框架，传递 Action 相当于 "emit "，将它弱化考虑，另外，Dispatcher 也可弱化，reflux 相比官方的 React flux，一个重要改进就是去掉 Dispatcher，工具复杂性因此降了不少。

这么弱化、简化后，Flux 框架就剩 Store 与 View，参照 MVC 框架，这里 Store 与 MVC 中 Model 是对应的，某种程度上说，Flux 概念与 MVC 具备一定兼容性。

reflux 的 Store 仿 React Component 设计 API，学习成本进一步降低，遗憾的是它是多 Store 结构，一个 Store 对应一个 View（有时对应多个），Store 变多后容易让开发者感到困惑，许多属性设计一时想不清楚该放在 Store，还是放在 View，经常换来换去。这里我没说多 Store 设计不对，单 Store 有单 Store 的问题。而是，多 Store 与 多 View 之间如何思考定位有点拧巴，不像 MVVM 那么直接。

MVVM 采用双向绑定，View 的变动自动反映到 ViewModel，这是非常简单易用的方式，MVVM 在人性化方面比前端其它框架好出很多，因为设计一项功能，开发者首先想的是界面怎么体现，加个按钮，还是加个输入框，然后围绕着按钮或输入框，思考有什么动作，比如，点击按钮后下一步做什么。换成 Flux 思考方式，Store 与 View 之间如何交互要多思考一次，还不以 "界面该怎么呈现" 为思考原点，因为 Action 与 Dispatch 的设计促使你先考虑 Store 的数据结构。

如果让 MVVM 再支持 "所见即所得" 的可视化设计，它的易用性将拉开 Flux 更远，加上 Flux 天然的函数式编程倾向，叠加 react-router 等工具，也自然以路由指令、Action命令、状态数据为思考出发点。比如 react-router 强调，以 "路由" 如何设置为功能开发的第一出发点，不像 MVVM 是以交互界面设计为第一出发点。所以，说句实话，React 生态链上的工具比 Vue 难用得多，这也是 React 急需 Shadow Widget 之类工具的理由。

现在我们明确了引入 MVVM 的收益，非常值得做。问题关键是，它如何与 Flux 共存？

首先，Flux 中的 Store 与 Controller View 可以合并，大胆一点，肯定不会死人。以 reflux 现有设计为例，如果一个 React Component 节点不显示到界面，比如

  

    

      
      添加
    
    

      

    
  

idSetter["btn_todo"] = function(value,oldValue) {
  if (value <= 2) {
    if (value == 1) {  // init process
      this.setEvent( {
        $onClick: function(event) {
          var inputComp = this.componentOf("//input");
          var text = inputComp.duals.value.trim();
          if (text) {
            var dataComp = this.componentOf(0);
            dataComp.duals.data = ex.update(dataComp.duals.data, {
              $push:[{text:text}],
            });
            inputComp.duals.value = "";
          }
        },
      });
    }
    return;
  }
};

msup

男|高级讲师

我要关注 我要私信

TA的文章

阅读更多

• 如何在godaddy购买主机-godaddy主机怎么样？

  阅读 1107·2021-09-22 15:37

• OpenInfra 基金会已与微软签署协议，成为最新的白金会员

  阅读 1133·2021-09-13 10:27

• Aperture：$10.3/月/1GB内存/8GB空间/600GB流量/150Mbps-500Mb

  阅读 2472·2021-08-25 09:38

• JS 中 __proto__ 和 prototype 存在的意义是什么？

  阅读 2448·2019-08-26 11:42

• 现代CSS进化史

  阅读 1529·2019-08-26 11:39

• JavaScript数据结构与算法（十）自平衡树

  阅读 1556·2019-08-26 10:58

• vue-video-player使用笔记（兼容m3u8）

  阅读 2323·2019-08-26 10:56

• 结合作用域，执行上下文图解闭包

  阅读 2570·2019-08-23 18:08

最新活动