Shadow Widget 內(nèi)部一律改用 React.createClass() 引入 Component 行為定義，因?yàn)橹苯又С?ES5 規(guī)格的代碼，不必經(jīng) Babel 轉(zhuǎn)譯，這看上去很土，卻很實(shí)用。例如：

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");
  },
};

不過(guò) Shadow Widget 不排斥用 ES6 編程，自定義一個(gè) Component 類(lèi)可以用 ES6+ 語(yǔ)法，只需從已有的，符合 Shadow Widget 規(guī)格的 Component 類(lèi)開(kāi)始繼承，不能從 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;

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

撇開(kāi)網(wǎng)頁(yè)設(shè)計(jì)的專(zhuān)有屬性，任何產(chǎn)品開(kāi)發(fā)都要求設(shè)計(jì)者先考慮用戶(hù)怎么操作，UI 可視化設(shè)計(jì)過(guò)程，也就是定義用戶(hù)需求，并把需求往各層設(shè)計(jì)分解的過(guò)程。所以，界面設(shè)計(jì)是承上啟下的，它應(yīng)在編碼之前進(jìn)行，而不是與編碼混雜同步進(jìn)行，也不是先寫(xiě)底層代碼，被動(dòng)的跟隨變化。對(duì)于網(wǎng)頁(yè)產(chǎn)品更如此，只要不拿網(wǎng)頁(yè)開(kāi)發(fā)命令行程序，網(wǎng)頁(yè)就是用戶(hù)交互操作最直接的媒介。

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

Vue 易用性勝過(guò) React，很大程度上是因?yàn)?MVVM 中的 component 定義與界面表現(xiàn)一一對(duì)應(yīng)，思考很直接。Shadow Widget 則在 MVVM 基礎(chǔ)上增強(qiáng)了即時(shí)可視化能力，以所見(jiàn)即所得的方式讓每次閉環(huán)疊代的周期縮短，從而讓開(kāi)發(fā)更加敏捷。

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

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

支持可視化設(shè)計(jì)的第一步，分離 Component 的界面表現(xiàn)與它的行為定義，即，在設(shè)計(jì)態(tài)我們?cè)诳梢曉O(shè)計(jì)器中只展示各 Componet 的可視特征，而不捆綁它的行為定義（比如 onClick 事件處理），當(dāng)產(chǎn)品正式運(yùn)行時(shí)，即，非設(shè)計(jì)態(tài)，各 Component 的行為定義將在初始化時(shí)正常捆綁。Shadow Widget 可視設(shè)計(jì)的輸出是 “轉(zhuǎn)義標(biāo)簽”，保存在當(dāng)前 *.html 文件中，行為定義則記錄在 js 文件，這兩者類(lèi)似于 Delphi 的 *.frm 界面定義文件與 *.pas 代碼實(shí)現(xiàn)文件。

可視化設(shè)計(jì)第二步，引入 MVVM 架構(gòu)。

Shadow Widget 內(nèi)部采用 Object.defineProperty() 定義雙源屬性，使得類(lèi)似 comp.duals.attr = value 的賦值語(yǔ)句能自動(dòng)觸發(fā)預(yù)設(shè)的 setter 函數(shù)。之后再對(duì)雙源屬性增加偵聽(tīng)機(jī)制，凡被 listen 的 duals.attr，其值變化會(huì)按事件方式被訂閱，進(jìn)而構(gòu)造聯(lián)動(dòng)觸發(fā)機(jī)制。

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

支持可視化設(shè)計(jì)第三步，讓 MVVM 架構(gòu)與 Flux 單向數(shù)據(jù)流協(xié)同工作。

這里只扼要解釋?zhuān)院筮€會(huì)專(zhuān)門(mén)寫(xiě)文章介紹。在 Shadow Widget 中，各 Component 若未按編程方式參與行為定制（專(zhuān)指在 main[sPath] 定義投影類(lèi)，或用 idSetter[sId] 實(shí)現(xiàn)定義），就視作 View 節(jié)點(diǎn)，凡參與定制的 Component 視作 ViewModel，各 ViewModel 節(jié)點(diǎn)使用的 props.attr 與 duals.attr 屬于 Model。這是一種通過(guò)擴(kuò)展虛擬 DOM 節(jié)點(diǎn)的能力而實(shí)現(xiàn)的機(jī)制，并不直接干擾 Flux 單向數(shù)據(jù)流機(jī)制，有影響的是，我們要采用多 Store 而非單 Store 機(jī)制，另外還要把 Component 節(jié)點(diǎn)復(fù)用為 Store 節(jié)點(diǎn)，用雙源屬性支持 action 分發(fā)（dispatch）與觸發(fā)（trigger）。

可視化設(shè)計(jì)與 MVVM 架構(gòu)密不可分，React 技術(shù)棧與 Flux 機(jī)制密不可分，它的 Functional React Programming 理念與可視化編程可以兼容，MVVM 主導(dǎo)上層些、粗粒度的設(shè)計(jì)，細(xì)粒度與橫向聯(lián)系由 FRP 主導(dǎo)。兩者交匯點(diǎn)就是參與行為定制的、可視的 Component 節(jié)點(diǎn)，也就是 ViewModel 節(jié)點(diǎn)。雙源屬性同時(shí)支撐 MVVM 框架與 FRP 框架，兩種框架分別主管 “縱向嵌套定義界面” 與 “橫向消息聯(lián)系”，處理過(guò)程非常自然。

各個(gè)主流前端框架都使用 NodeJS 集結(jié)工具鏈，它們都考慮了規(guī)范化、工程化開(kāi)發(fā)的需求，都用 NPM 包管理各層庫(kù)的依賴(lài)關(guān)系，但它們普遍沒(méi)為技術(shù)分層帶來(lái)的人員分工，在框架層面提供有效支持。

無(wú)論 Angular，React，還是 Vue，都是重框架，輕不起來(lái)，快速入門(mén)不能算輕，要以真正能開(kāi)發(fā)產(chǎn)品、獨(dú)立解決問(wèn)題為準(zhǔn)，學(xué)透這些框架都要花不少時(shí)間。回想十年前，前端開(kāi)發(fā)是一個(gè)實(shí)習(xí)生簡(jiǎn)單翻翻參考書(shū)就能做的，現(xiàn)在要有一年以上經(jīng)驗(yàn)才算入門(mén)，而且，不同素質(zhì)的人產(chǎn)出代碼的質(zhì)量相差很遠(yuǎn)。前端開(kāi)發(fā)該對(duì)人員分層管理了，這是既是工程化開(kāi)發(fā)的需求，也是產(chǎn)品開(kāi)發(fā)趨于復(fù)雜化必然提出的要求。

Shadow Widget 所構(gòu)筑的技術(shù)體系，將前端開(kāi)發(fā)劃分為兩大部分：構(gòu)件（Widget）開(kāi)發(fā)與界面（GUI）開(kāi)發(fā)。前者要求分發(fā)者具備完整技能，后者則只需簡(jiǎn)單技能，即：會(huì)用 html、css、javascript，掌握 react 入門(mén)知識(shí)，借助界面可視化設(shè)計(jì)器很快就能勝任工作。也就是說(shuō)，我們預(yù)想前端開(kāi)發(fā)人員至少可分兩類(lèi)，一類(lèi)是入門(mén)級(jí)的，實(shí)習(xí)生水準(zhǔn)，他主要工作是拿別人已開(kāi)發(fā)好的構(gòu)件搭積木，另一類(lèi)是高級(jí)工程師，他為前一類(lèi)開(kāi)發(fā)者開(kāi)發(fā)構(gòu)件。

相信所有老板都喜歡這么分工，能省錢(qián)！專(zhuān)業(yè)化分工后，整體開(kāi)發(fā)效率與質(zhì)量都會(huì)提升。

(本文完)