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

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

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

典型的 Flux 框架中，Store 與 View 之間的關系如下：

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

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

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

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

新增如下界面設計：

相應的，增加一個 Functionarity Block，JS 編碼如下：

(function() { // functionarity block

var configComp = null;

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

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

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

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

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

說明，Flux 是 FRP（Functional Reactiv Programming）開發思想的一種實現，對于 React 開發，上面所提 Flux 與 FRP 基本等效。

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

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

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

界面設計過程中，若想查看不同數據初值會驅動什么樣的界面形態，不妨啟用 W.$dataSrc 定義，比如前面例子界面缺省顯示 Celsius 溫度格式，因為 ".body.calculator.field" 節點的 scale 屬性初值是 "c"，現在我們想檢查 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" }，用來預定義哪個節點要附加哪些屬性的初值。

上面代碼可以寫入獨立的 js 文件，多個此類 js 文件可構造不同的調測場景，然后用