摘要：本文介紹應(yīng)用于通用開發(fā)的最佳實踐，只聚焦于典型場景下最優(yōu)開發(fā)方法。結(jié)合的可視化設(shè)計新近推出版本，設(shè)計方式在體系得到完整支持了。注此項為建議，不強制面板之下不能直接放行內(nèi)構(gòu)件，要在面板下放置類構(gòu)件后，才能放類構(gòu)件。

本文介紹 "React + Shadow Widget" 應(yīng)用于通用 GUI 開發(fā)的最佳實踐，只聚焦于典型場景下最優(yōu)開發(fā)方法。分上、下兩篇講解，下篇講述正交框架分析模式與常用調(diào)測方法。

查閱上篇 請點擊這里，Shadow Widget 開源項目 在這里。

典型的 Flux 框架中，Store 與 View 之間的關(guān)系如下：

本圖摘自 fluxxor.com 的 “What is Flux?” 一文，Store 中的數(shù)據(jù)傳遞給一個 Component，這個 Component 又通過 props 屬性驅(qū)動多層 Component 子節(jié)點來展示界面。在這種數(shù)據(jù)傳遞關(guān)系中，多個 Component 都是 View，但從 Store 獲得數(shù)據(jù)的那個 View 比較特殊，稱為 "Controller View"（見上圖）。將 Controller View 與 View 對應(yīng)到 Shadow Widget 的 MVVM 框架，Controller View 就是 VM（ViewModel），由 VM 驅(qū)動的子級 Component 就是 V (View)。

然而現(xiàn)實編程并非上圖那么簡單，Controller View 的子節(jié)點，也即 View 節(jié)點，有時很復(fù)雜，其外部若只依賴從上級 props 傳遞下來的數(shù)據(jù)來驅(qū)動渲染，會很別扭。開發(fā)者常不由自主的放棄 “純凈” 的編程模式，突破限制，讓 View 也從全局變量讀數(shù)據(jù)，即，變相的把部分數(shù)據(jù)從 Store 分離出去，改用全局變量表達，或者干脆讓 View 也直接從 Store 讀數(shù)據(jù)，而不是只用 Controller View 代傳的數(shù)據(jù)。

Shadow Widget 將問題簡化，既然 Store 主要用于存貯數(shù)據(jù)，那就還原它的數(shù)據(jù)特性，作為數(shù)據(jù)，在哪兒定義關(guān)系不大，直接拿 Component 的屬性存貯數(shù)據(jù)就好，將 Store 并入 Component 沒有不可逾越的障礙，當(dāng)然，前提是我們已設(shè)計了 “雙源屬性” 與 “W 樹” 機制。然后，Controller View 及其下級多個 View，合起來視作一個 FB（Functionarity Block），在同一 Functionarity Block Namespace 下用 javascript 定義各節(jié)點行為。把相關(guān)節(jié)點的投影定義寫一起，很大程度消除了節(jié)點間隔閡，因為，你能隨時可以定義一個變量用來傳數(shù)據(jù)。

接本文上篇的例子，假定我們在原功能基礎(chǔ)上，再增加 “全局配置” 的功能，提供 3 個可選項：“自動選 Celsius 還是 Fahrenheit 格式”、“固定用 Celsius”、“固定用 Fahrenheit”。其中，第一個選項 Auto（自動選格式）依據(jù)瀏覽器特性推斷國別信息，然后智能選擇 Celsius 或 Fahrenheit。

新增如下界面設(shè)計：

相應(yīng)的，增加一個 Functionarity Block，JS 編碼如下：

(function() { // functionarity block

var configComp = null;

idSetter["config"] = function(value,oldValue) {
  // ...
};
})();

該 FB 的入口節(jié)點是 configComp。再接著細化設(shè)計，我們該將 configComp 定義挪到全局變量定義區(qū)，因為該節(jié)點在兩個 FB 功能塊都用到。

為方便講述起見，我們把這兩個 FB 分別稱為 config 與 calculator，以 FB 分布為橫軸，以 W 樹為縱軸，W 樹中的節(jié)點是層層串聯(lián)的，繪制這兩個 FB 的分布如下圖：

當(dāng)我們整體設(shè)計 GUI 時，應(yīng)以 MVVM 方式思考。結(jié)合本例，也就是規(guī)劃 config 與 calculator 兩個 “功能塊”，確定各功能塊的入口節(jié)點，以及它的上下層串接關(guān)系。而處理各個功能塊之間聯(lián)動關(guān)系時，應(yīng)切換到 Flux 單向數(shù)據(jù)流思考方式。

總結(jié)一下，整個 HTML 頁面是一顆 DOM 樹，是縱向的，在這顆樹劃分若干功能塊的過程，是基于 MVVM 為主的設(shè)計過程；而處理各功能塊之間橫向聯(lián)系，則以 FRP 思路為主導(dǎo)。這一縱一橫的思考方式，我們稱為 “正交框架” 分析模式。

說明，F(xiàn)lux 是 FRP（Functional Reactiv Programming）開發(fā)思想的一種實現(xiàn)，對于 React 開發(fā)，上面所提 Flux 與 FRP 基本等效。

至于 FB 之間的功能如何交互，如果處理邏輯簡單，不妨在相關(guān) FB 代碼塊中直接寫代碼，如果邏輯復(fù)雜，不妨取相關(guān) FB 的共有父節(jié)點作為入口節(jié)點，新設(shè)一個 FB 功能塊。取共有父節(jié)點的主要作用是，該父節(jié)點從創(chuàng)建到 unmount，可以覆蓋其下所有節(jié)點的生存周期，在它的 idSetter 函數(shù)中編程會方便一些。

在可視設(shè)計器中開發(fā)界面的過程，可能存在破壞式重構(gòu)，比如你在某個 FB 的入口節(jié)點指定 data 屬性值，然后它的子節(jié)點根據(jù) data 取值自動生成子節(jié)點，如果你給定的 data 初始值格式不對，其下子節(jié)點會無法生成。所給初值不對可能因為設(shè)計變化了，你的 data 格式還沒來得及調(diào)整。

為了最大幅度減少上述破壞式重構(gòu)帶來錯誤，在設(shè)計界面時，我們建議用作驅(qū)動源頭的數(shù)據(jù)初值應(yīng)取 “空” 值，比如賦給 null 或 [] 之類的值。

界面設(shè)計過程中，若想查看不同數(shù)據(jù)初值會驅(qū)動什么樣的界面形態(tài)，不妨啟用 W.$dataSrc 定義，比如前面例子界面缺省顯示 Celsius 溫度格式，因為 ".body.calculator.field" 節(jié)點的 scale 屬性初值是 "c"，現(xiàn)在我們想檢查 scale="f" 界面是否正確。按如下方式使用兩行代碼即可：

if (!window.W) { window.W = new Array(); W.$modules = [];}
W.$modules.push( function(require,module,exports) {

var W = require("shadow-widget");

var dataSrc = W.$dataSrc = {};
dataSrc[".body.calculator.field"] = { "scale": "f" };

});

其中，var dataSrc = W.$dataSrc = {} 表示啟用 W.$dataSrc，缺省是不啟用的。另一句 dataSrc[".body.calculator.field"] = { "scale": "f" }，用來預(yù)定義哪個節(jié)點要附加哪些屬性的初值。

上面代碼可以寫入獨立的 js 文件，多個此類 js 文件可構(gòu)造不同的調(diào)測場景，然后用