React 可视化开发工具 shadow-widget 最佳实践（下）

本文介绍 "React + Shadow Widget" 应用于通用 GUI 开发的最佳实践，只聚焦于典型场景下最优开发方法。分上、下两篇讲解，下篇讲述正交框架分析模式与经常使用调测方法。

查阅上篇 请点击这里，Shadow Widget 开源项目 在这里。

1. Controller View 与 View

典型的 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 定义各节点行为。把相关节点的投影定义写一块儿，很大程度消除了节点间隔阂，由于，你能随时能够定义一个变量用来传数据。

2. 正交框架分析模式

接本文上篇的例子，假定咱们在原功能基础上，再增长 “全局配置” 的功能，提供 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 函数中编程会方便一些。

3. 挂载数据来驱动调测

在可视设计器中开发界面的过程，可能存在破坏式重构，好比你在某个 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 文件可构造不一样的调测场景，而后用 <script> 标签按需把某一个 js 文件导入到被测页面。

4. 结合 shadow-bootstrap 的可视化设计

shadow-bootstrap 新近推出 v1.1 版本，Bootstrap 设计方式在 Shadow Widget 体系获得完整支持了。

Bootstrap 提供了优秀的前端控件库，在 shadow-widget 上用 bootstrap 堪称完美，毕竟上百个 class 类谁都记不住，你们作开发时，要不停的查手册。用 shadow-widget 的可视化设计器，只需从右侧样板页拖一个样板扔进来，就建立你想要的构件了，而后选择相应节点，把相关属性配置一下，你的界面很快就作好。

上图是其中一个样板页，该拖入哪一个样板，看一眼就能区分，再也不受那么多 class 类名困扰了。

5. 注意事项

刚开始使用 Shadow Widget 时，你们可能不适应它的可视化设计，容易忘掉几项设计约束，简单举几个例子：

1. 在根节点（即 ".body" 节点）下只能摆放面板与绝对定位的构件（如 ScenePage 等），即首层节点要么是 Panel 类构件，要么是指定 position='absolute' 的非行内构件。
2. 绝对定位的构件，应挂到根节点，不宜在其它地方出现。（注：此项为建议，不强制）
3. 面板之下不能直接放行内构件，要在面板下放置 P 类构件后，才能放 Span 类构件。
4. 一个构件要么启用 "html." 属性，要么使用它的若干子节点，二者只能二选一，若定义子节点了，以 "html." 表示文本将被忽略。

总之，与界面设计打交道，设计老是具体的，你要面对各种封装好的构件，很多构件有特殊要求，《Shadow Widget 用户手册》有全面介绍，有必要通读该手册。

6. 关于团队分工

Shadow Widget 最佳实践还建议团队成员要按技能分工，至少有两个工种，其一是能运用他人已封装好的 WTC 类或库化 UI，进行 GUI 开发；其二是为他人封装 WTC 类或库化 UI。前者对技能要求不高，后者则要求深刻掌握 React 与 Shadow Widget 知识。

对于微型团队，也应按上述分工的思路规划您的产品开发，由于这两种分工的目标不一样，前者着眼短时间目标，尽快把产品作出来，把界面弄漂亮些，后者着眼中长期目标，用封装库提升开发复用率。即便是单人团队，一样须要分工，无非在时间上错开，一段时间承担一种角色，另外一段时间换一个角色。

Shadow Widget 当前的 WTC 类与界面库还不够丰富，但它的架子已搭好，起点不低。它的定制扩展能力出色，已经过一些上规模代码的产品检验，如 shadow-bootstrap， pinp-blogs 等，具有必定成熟度。咱们有理由相信，这个产品会随着扩展库逐渐增多，前景愈来愈光明。

（本文完）