Shadow Widget 內部一律改用 React.createClass() 引入 Component 行為定義，因為直接支持 ES5 規格的代碼，不必經 Babel 轉譯，這看上去很土，卻很實用。例如：

main[".body.top.p.tool"] = {
  getDefaultProps: function() {
    var props = T.Button.getDefaultProps();
    // props.attr = value;
    return props;
  },

  getInitialState: function() {
    var state = this._getInitialState(this);
    // ...
    return state;
  },

  $onClick: function(event) {
    alert("clicked");
  },
};

不過 Shadow Widget 不排斥用 ES6 編程，自定義一個 Component 類可以用 ES6+ 語法，只需從已有的，符合 Shadow Widget 規格的 Component 類開始繼承，不能從 React.Component 繼承，例如：

class MyButton_ extends T.Button_ {
  constructor(name,desc) {
    super(name,desc);
  }
  
  getDefaultProps() {
    var props = super.getDefaultProps();
    // props.attr = value;
    return props;
  }

  getInitialState() {
    var state = super.getInitialState();
    // ...
    return state;
  }

  $onClick: function(event) {
    alert("clicked");
  }
}

// convert to React class
var AbstractButton = new MyButton_();
var MyButton = AbstractButton._createClass({});
var jsx = test;

var MyButton2 = AbstractButton._createClass( {
  $onClick: function(event) {
    alert("another onClick");
  }
});
var jsx2 = test2;

注意到了嗎？上面代碼沒有直接定義 React class，而是加了一層抽象，AbstractButton 是類的類，用 AbstractButton._createClass() 才實例化成 React class。這么設計，一方面讓 Component 定義正常使用類繼承，另一方面讓 Component 的界面表現能有選擇的與行為定義分離，這是在線支持可視化設計的基礎。

撇開網頁設計的專有屬性，任何產品開發都要求設計者先考慮用戶怎么操作，UI 可視化設計過程，也就是定義用戶需求，并把需求往各層設計分解的過程。所以，界面設計是承上啟下的，它應在編碼之前進行，而不是與編碼混雜同步進行，也不是先寫底層代碼，被動的跟隨變化。對于網頁產品更如此，只要不拿網頁開發命令行程序，網頁就是用戶交互操作最直接的媒介。

React 的 JSX 設計方式讓 GUI 設計混合于編碼之中，未保證界面設計的第一性，其主流的 Flux 工具，均強化了數據傳遞如何設計，讓開發者一上來就思考 action 與 store 怎么設計，而非界面該如何表現。react-route 更為極端，它鼓勵大家第一步就思考路由，并以此為提綱展開各項設計，很不人性。Shadow Widget 第一步就要求考慮界面如何表現，而且只在 UI 設計想清楚后再做別的，然后第二步、第三步才考慮數據如何流動、路由如何規劃等，讓 “網頁開發” 回歸常規 GUI 開發，這才是正確的姿勢。

Vue 易用性勝過 React，很大程度上是因為 MVVM 中的 component 定義與界面表現一一對應，思考很直接。Shadow Widget 則在 MVVM 基礎上增強了即時可視化能力，以所見即所得的方式讓每次閉環疊代的周期縮短，從而讓開發更加敏捷。

拿具體例子解釋上面意思，比方設計一個播放器，有兩種思考方式，第一種，先理清界面交互方式，是否為了區分連接播放與只播放單個音頻，在界面設計兩個播放按鈕，還是共用一個按鈕（但另加 “是否連續播放” 選項框）？要不要提供暫停按鈕？暫停按鈕是否與播放按鈕并合？第二種思考方式，先確定用到哪些數據，數據又由哪些 action 驅動，比如要有播放器與播放列表，要定義一個狀態屬性表示暫停或播放中，驅動它變更的 action 有 play, pause, stop 等，還要有一個 “是否連續播放” 屬性，與播放列表一起作為 payload 附在 play action 上傳遞，播放列表還有增刪改 action，等等。

雖然這兩種思考方式都能達到目的，但從嚴格意義上講，選擇哪一種是工作方法對錯的問題，而不是個人風格喜好的問題。第二種思考方式錯誤在于，“容易偏離需求” 與 “喪失需求分解層次感”，至于 “設計過程欠直觀” 還是次要的、附帶的。容易偏離需求，比如你為手表設計播放器，增加的 “是否連續播放” 選項在界面擺不下，若采用第二種思考方式你很容易忽略這個限制。另外，設計過程是有層次的，自頂向下，由粗入細，需求在各層設計逐步分解，上一層操作方式變化會影響下一層如何設計，如果以數據與 action 為思考出發點，很容易喪失設計層次感，沒有前置思考界面如何交互，上層如何表現對下層設計的影響也容易被延后思考，甚至扭曲了。

支持可視化設計的第一步，分離 Component 的界面表現與它的行為定義，即，在設計態我們在可視設計器中只展示各 Componet 的可視特征，而不捆綁它的行為定義（比如 onClick 事件處理），當產品正式運行時，即，非設計態，各 Component 的行為定義將在初始化時正常捆綁。Shadow Widget 可視設計的輸出是 “轉義標簽”，保存在當前 *.html 文件中，行為定義則記錄在 js 文件，這兩者類似于 Delphi 的 *.frm 界面定義文件與 *.pas 代碼實現文件。

可視化設計第二步，引入 MVVM 架構。

Shadow Widget 內部采用 Object.defineProperty() 定義雙源屬性，使得類似 comp.duals.attr = value 的賦值語句能自動觸發預設的 setter 函數。之后再對雙源屬性增加偵聽機制，凡被 listen 的 duals.attr，其值變化會按事件方式被訂閱，進而構造聯動觸發機制。

雙源屬性解決了類似 Vue 中數據雙向綁定的需求，ViewModel 建立在數據流自動傳遞基礎上，Shadow Widget 為此還增加 $if, $elif, $else, $for 等控制指令，讓界面能按特定規則由數據驅動自動生成，再有 trigger 機制、可計算屬性、棧式調用空間等設計，讓數據傳遞、組裝、條件控制等變得靈活、強大。總之，Shadow Widget 的 MVVM 機制與 Vue 基本類似，限于篇幅本文不展開介紹。

支持可視化設計第三步，讓 MVVM 架構與 Flux 單向數據流協同工作。

這里只扼要解釋，以后還會專門寫文章介紹。在 Shadow Widget 中，各 Component 若未按編程方式參與行為定制（專指在 main[sPath] 定義投影類，或用 idSetter[sId] 實現定義），就視作 View 節點，凡參與定制的 Component 視作 ViewModel，各 ViewModel 節點使用的 props.attr 與 duals.attr 屬于 Model。這是一種通過擴展虛擬 DOM 節點的能力而實現的機制，并不直接干擾 Flux 單向數據流機制，有影響的是，我們要采用多 Store 而非單 Store 機制，另外還要把 Component 節點復用為 Store 節點，用雙源屬性支持 action 分發（dispatch）與觸發（trigger）。

可視化設計與 MVVM 架構密不可分，React 技術棧與 Flux 機制密不可分，它的 Functional React Programming 理念與可視化編程可以兼容，MVVM 主導上層些、粗粒度的設計，細粒度與橫向聯系由 FRP 主導。兩者交匯點就是參與行為定制的、可視的 Component 節點，也就是 ViewModel 節點。雙源屬性同時支撐 MVVM 框架與 FRP 框架，兩種框架分別主管 “縱向嵌套定義界面” 與 “橫向消息聯系”，處理過程非常自然。

各個主流前端框架都使用 NodeJS 集結工具鏈，它們都考慮了規范化、工程化開發的需求，都用 NPM 包管理各層庫的依賴關系，但它們普遍沒為技術分層帶來的人員分工，在框架層面提供有效支持。

無論 Angular，React，還是 Vue，都是重框架，輕不起來，快速入門不能算輕，要以真正能開發產品、獨立解決問題為準，學透這些框架都要花不少時間。回想十年前，前端開發是一個實習生簡單翻翻參考書就能做的，現在要有一年以上經驗才算入門，而且，不同素質的人產出代碼的質量相差很遠。前端開發該對人員分層管理了，這是既是工程化開發的需求，也是產品開發趨于復雜化必然提出的要求。

Shadow Widget 所構筑的技術體系，將前端開發劃分為兩大部分：構件（Widget）開發與界面（GUI）開發。前者要求分發者具備完整技能，后者則只需簡單技能，即：會用 html、css、javascript，掌握 react 入門知識，借助界面可視化設計器很快就能勝任工作。也就是說，我們預想前端開發人員至少可分兩類，一類是入門級的，實習生水準，他主要工作是拿別人已開發好的構件搭積木，另一類是高級工程師，他為前一類開發者開發構件。

相信所有老板都喜歡這么分工，能省錢！專業化分工后，整體開發效率與質量都會提升。

(本文完)