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

不過 Shadow Widget 不排斥用 ES6 編程，自定義一個(gè) Component 類可以用 ES6+ 語法，只需從已有的，符合 Shadow Widget 規(guī)格的 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() 才實(shí)例化成 React class。這么設(shè)計(jì)，一方面讓 Component 定義正常使用類繼承，另一方面讓 Component 的界面表現(xiàn)能有選擇的與行為定義分離，這是在線支持可視化設(shè)計(jì)的基礎(chǔ)。

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

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

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

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

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

支持可視化設(shè)計(jì)的第一步，分離 Component 的界面表現(xiàn)與它的行為定義，即，在設(shè)計(jì)態(tài)我們在可視設(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 文件，這兩者類似于 Delphi 的 *.frm 界面定義文件與 *.pas 代碼實(shí)現(xiàn)文件。

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

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

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

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

這里只扼要解釋，以后還會專門寫文章介紹。在 Shadow Widget 中，各 Component 若未按編程方式參與行為定制（專指在 main[sPath] 定義投影類，或用 idSetter[sId] 實(shí)現(xiàn)定義），就視作 View 節(jié)點(diǎn)，凡參與定制的 Component 視作 ViewModel，各 ViewModel 節(jié)點(diǎn)使用的 props.attr 與 duals.attr 屬于 Model。這是一種通過擴(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)系”，處理過程非常自然。

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

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

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

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

(本文完)