摘要：是分發(fā)器，是數(shù)據(jù)與邏輯處理器，會在注冊針對各個命令字的響應回調(diào)函數(shù)。當按如下方式觸發(fā)回調(diào)時，回調(diào)函數(shù)具備事件的特性。

本系列博文從 Shadow Widget 作者的視角，解釋該框架的設(shè)計要點。本篇解釋 Shadow Widget 在 MVC、MVVM、Flux 框架之間如何做選擇。

Facebook 官方為 React 提出了 flux 框架，也自己實現(xiàn)了一個 flux.js，盡管這個庫設(shè)計得很差勁，但所有第三方為 React 開發(fā)的單向數(shù)據(jù)流方案，起點都是該庫官方所提的 Flux concepts，下面是經(jīng)典結(jié)構(gòu)圖：

Action 可簡單理解為指令（或命令），由命令字 type 與命令參數(shù) data（或稱 payload）組成。Dispatcher 是分發(fā)器，Store 是數(shù)據(jù)與邏輯處理器，Store 會在 Dispatcher 注冊針對各個命令字的響應回調(diào)函數(shù)。View 就是 React Component，View 常使用 Store 中的數(shù)據(jù)并訂閱 Store 發(fā)生變化來刷新自身顯示。

幾個部件之間數(shù)據(jù)單向流動，如下：

  Action -> Dispatcher -> Store -> View

形成單向流動的原理較簡單，大致這樣，Store 在 Dispatch 注冊的回調(diào)函數(shù)，由 Action 觸發(fā)，Dispatcher 解析命令字，找出相應回調(diào)用函數(shù)實現(xiàn)調(diào)用即可。當 Dispatcher 按如下方式觸發(fā)回調(diào)時，回調(diào)函數(shù)具備事件的特性。

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

如果立即調(diào)用 callback，那只是回調(diào)，如果延時 0 秒會讓 callback 在下個周期被調(diào)用，就成事件了，單向數(shù)據(jù)流因此得到保證。

當然，上面介紹非常簡略，把核心機制講明白，reflux、redux 讓注冊回調(diào)變事件也都用這個機制。當然，事件化回調(diào)的處理過程可能很復雜，比如 Dispatcher 還提供 waitFor() 等待一項或多項 Action 的接口，我們略去不細講。

React 實現(xiàn)的虛擬 DOM 部分（即核心庫 react.js 與 react-dom.js）是 MVC 中的 "V"，其 MVC 框架圖如下：

當你只使用 React 的核心庫，未使用 reflux、redux 等單向數(shù)據(jù)流機制時，所用的 MVC 就是上圖樣子。如何構(gòu)造 Controller 與 Model 是自由的，甚至你想將它改造成 MVVM 也是自由的，畢竟 React 的核心庫只提供虛擬 DOM 映射，與 HTML 原生的 DOM 一起提供 "View"。后面我們真的要介紹怎么改成 MVVM。

Flux、MVC、MVVM 這三者是對等的架構(gòu)，我們不能直接將 Flux 框架往 MVC 上套。

在 React 中使用 MVC 主要缺陷是：當應用規(guī)模變大，M, V, C 之間依賴關(guān)系會變復雜。下圖還不算太復雜，只用到 2 個 Module。

React 虛擬 DOM 對真實 DOM 做了一次抽像，附加 props、state 等概念，再加上異步時序干擾，原先還勉強玩得轉(zhuǎn)的 MVC，已變得很不好用，開發(fā)、調(diào)試、定位問題都變困難了。

引入 Flux 能有針對性的緩解上述困難。其一，用單數(shù)據(jù)流向串接各 View，讓與 Model 交互的那個 View（也稱 Controller View）承擔設(shè)計復雜性，其它 View 只做簡單工作，如展示界面、簡單響應鼠標點擊等操作。

其二，用 Action 與 Dispatcher 簡化 Controller，不弄那么多 Controller，歸總到一個 Dispatcher。其三，采用 Functional Reactive Programming 方法構(gòu)造響應式的單向數(shù)據(jù)流機制，以此應對異步時序問題。

React 生態(tài)鏈中有多種 Flux 實現(xiàn)，他們本質(zhì)一樣，表面差別不算大，通常幾句話就能概括。reflux 采用多 store 方案，把用于集中分發(fā)的 Dispatcher 簡化掉了，redux 采用單 store 方案，把分發(fā) Action 后的處理分解給眾多 Reducer 函數(shù)，也就是說，上圖多個 Store 的功能，用 "單 Store + 眾多 Reducer 函數(shù)" 替換。

Redux 最大優(yōu)點是實施徹底函數(shù)式編程，最大缺點也是徹底函數(shù)式。它本身并未簡化設(shè)計復雜性，只是轉(zhuǎn)移復雜性，但按官方原生的 Flux 概念，我們是按對象方式理解一個個 Store 的，在設(shè)計時，處理 Store 與 View，以及與 Action 之間關(guān)系時，都按對象方式去思考的，現(xiàn)在把復雜性轉(zhuǎn)移到眾多 reducer 函數(shù)上，函數(shù)式思維不利于設(shè)計分解（相對對象化思維而言）。

Redux 之所以能盛行，與 React 自身限制有關(guān)。React 的虛擬 DOM 樹限制數(shù)據(jù)單向（向下）傳遞，跨節(jié)點讀取屬性極不方便，如果我們把所有服務于 render 的 state 數(shù)據(jù)，獨立到節(jié)點之外的全局函數(shù)（reducer）中去組裝呢？所有用到的 state 串一起，形成一個大的全局變量（就是單 Store），reducer 函數(shù)想怎么讀就怎么讀。這個方案以大幅度函數(shù)式改造為代價，來突破 React 的限制。

Shadow Widget 做的正相反，嘗試維持對象化思維習慣，把 Store 與 ViewModel 合一（后面還有詳細說明）以便減輕思考負擔；通過建立 Widget 樹，用 this.componentOf() 快速檢索相關(guān)節(jié)點，以求方便的存取屬性；再設(shè)計 duals 雙源屬性，建立一套能自動識別數(shù)據(jù)變化，并驅(qū)動單向數(shù)據(jù)流的機制。

我們研究一下 Controller View 與 Store 對接及與下級 View 的連接關(guān)系，取上圖局部，放大講解，如下：

當 Store 中有數(shù)據(jù)更新，通知 Controller View 更新界面，Controller View 就從 Store 讀得 state 數(shù)據(jù)，來更新自己的 state。而自身 state 變化將觸發(fā)下級 View 聯(lián)動更新，變化的信息在各子級借助 props 屬性實現(xiàn)傳遞。

為下文講解作準備，這里我們先拎一拎 Store 該具備的特性：

要提供事件通知功能，當 Store 中的 state 數(shù)據(jù)有變化，通知 Controller View 刷新界面。

對 Controller View 暴露 state 數(shù)據(jù)，有兩種設(shè)計可選，一是讓事件通知中帶 state 數(shù)據(jù)，二是事件通知不帶數(shù)據(jù)，要由 Controller View 主動到 Store 查詢。結(jié)合 FRP 編程特點，第二個設(shè)計更好，如果數(shù)據(jù)連續(xù)多次更新，從 Store 讀數(shù)據(jù)應合并為一次，取最新值。

何時通知 Controller View 刷新可能比較復雜，涉及條件組合，比如要 Action A 與 Action B 都發(fā)生后，才能觸發(fā)事件通知。

我們換一個角度看 flux 框架，傳遞 Action 相當于 "emit "，將它弱化考慮，另外，Dispatcher 也可弱化，reflux 相比官方的 React flux，一個重要改進就是去掉 Dispatcher，工具復雜性因此降了不少。

這么弱化、簡化后，F(xiàn)lux 框架就剩 Store 與 View，參照 MVC 框架，這里 Store 與 MVC 中 Model 是對應的，某種程度上說，F(xiàn)lux 概念與 MVC 具備一定兼容性。

reflux 的 Store 仿 React Component 設(shè)計 API，學習成本進一步降低，遺憾的是它是多 Store 結(jié)構(gòu)，一個 Store 對應一個 View（有時對應多個），Store 變多后容易讓開發(fā)者感到困惑，許多屬性設(shè)計一時想不清楚該放在 Store，還是放在 View，經(jīng)常換來換去。這里我沒說多 Store 設(shè)計不對，單 Store 有單 Store 的問題。而是，多 Store 與 多 View 之間如何思考定位有點擰巴，不像 MVVM 那么直接。

MVVM 采用雙向綁定，View 的變動自動反映到 ViewModel，這是非常簡單易用的方式，MVVM 在人性化方面比前端其它框架好出很多，因為設(shè)計一項功能，開發(fā)者首先想的是界面怎么體現(xiàn)，加個按鈕，還是加個輸入框，然后圍繞著按鈕或輸入框，思考有什么動作，比如，點擊按鈕后下一步做什么。換成 Flux 思考方式，Store 與 View 之間如何交互要多思考一次，還不以 "界面該怎么呈現(xiàn)" 為思考原點，因為 Action 與 Dispatch 的設(shè)計促使你先考慮 Store 的數(shù)據(jù)結(jié)構(gòu)。

如果讓 MVVM 再支持 "所見即所得" 的可視化設(shè)計，它的易用性將拉開 Flux 更遠，加上 Flux 天然的函數(shù)式編程傾向，疊加 react-router 等工具，也自然以路由指令、Action命令、狀態(tài)數(shù)據(jù)為思考出發(fā)點。比如 react-router 強調(diào)，以 "路由" 如何設(shè)置為功能開發(fā)的第一出發(fā)點，不像 MVVM 是以交互界面設(shè)計為第一出發(fā)點。所以，說句實話，React 生態(tài)鏈上的工具比 Vue 難用得多，這也是 React 急需 Shadow Widget 之類工具的理由。

現(xiàn)在我們明確了引入 MVVM 的收益，非常值得做。問題關(guān)鍵是，它如何與 Flux 共存？

首先，F(xiàn)lux 中的 Store 與 Controller View 可以合并，大膽一點，肯定不會死人。以 reflux 現(xiàn)有設(shè)計為例，如果一個 React Component 節(jié)點不顯示到界面，比如

  

    

      
      添加
    
    

      

    
  

idSetter["btn_todo"] = function(value,oldValue) {
  if (value <= 2) {
    if (value == 1) {  // init process
      this.setEvent( {
        $onClick: function(event) {
          var inputComp = this.componentOf("http://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

男|高級講師

我要關(guān)注 我要私信

TA的文章

閱讀更多

• 如何在godaddy購買主機-godaddy主機怎么樣？

  閱讀 1116·2021-09-22 15:37

• OpenInfra 基金會已與微軟簽署協(xié)議，成為最新的白金會員

  閱讀 1143·2021-09-13 10:27

• Aperture：$10.3/月/1GB內(nèi)存/8GB空間/600GB流量/150Mbps-500Mb

  閱讀 2489·2021-08-25 09:38

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

  閱讀 2458·2019-08-26 11:42

• 現(xiàn)代CSS進化史

  閱讀 1538·2019-08-26 11:39

• JavaScript數(shù)據(jù)結(jié)構(gòu)與算法（十）自平衡樹

  閱讀 1573·2019-08-26 10:58

• vue-video-player使用筆記（兼容m3u8）

  閱讀 2333·2019-08-26 10:56

• 結(jié)合作用域，執(zhí)行上下文圖解閉包

  閱讀 2581·2019-08-23 18:08

最新活動