本文介绍“React+ShadowWidget”应用于一般GUI开发的最佳实践，只关注典型场景下的最佳开发方式。分为第一部分和第二部分两部分，第二部分介绍正交帧分析模式和常用调测方法。上一篇文章请点这里，ShadowWidget开源项目就在这里。1.ControllerView和View在一个典型的Flux框架中，Store和View的关系如下：本图摘自文章《什么是Flux？在fluxxor.com上。Store中的数据传递给一个Component，Component通过props属性驱动多层Component子节点显示界面。在这种数据传递关系中，多个Component都是View，但是从Store获取数据的View比较特殊，叫做“ControllerView”（见上图）。将ControllerView和View对应到ShadowWidget的MVVM框架，ControllerView就是VM（ViewModel），VM驱动的子Component就是V（View）。然而，现实世界的编程并不像上图那么简单。ControllerView的子节点，也就是View节点，有时候会很复杂。如果仅仅依靠上级道具传下来的数据来驱动渲染，那就很别扭了。开发者往往不由自主地放弃“纯”编程模式，突破局限，让View从全局变量中读取数据，也就是变相从Store中分离出一些数据，改用全局变量，或者干脆让View也从中读取数据Store读取数据，而不仅仅是ControllerView传递下来的数据。ShadowWidget简化了这个问题。由于Store主要是用来存储数据的，还原它的数据特性。作为数据，它在哪里定义并不重要。只需使用Component的属性来存储数据。将Store合并到Component中。一个不可逾越的障碍，当然前提是我们设计了“双源属性”和“W树”机制。然后，将ControllerView及其下属View统称为一个FB（FunctionarityBlock），在同一个FunctionarityBlockNamespace下，通过javascript定义各个节点的行为。将相关节点的投影定义写在一起，大大消除了节点之间的间隙，因为你可以随时定义一个变量来传递数据。2、正交坐标系分析模式继续上一篇文章的例子，假设我们在原有功能的基础上增加“全局配置”功能，提供3个选项：“自动选择摄氏或华氏格式”、“固定”摄氏度”，“固定为华氏度”。其中，第一个选项Auto（自动格式选择）会根据浏览器特性推断国家信息，然后智能选择摄氏度或华氏度。添加如下接口设计：相应地，添加一个FunctionarityBlock，JS代码如下：(function(){//functionarityblockvarconfigComp=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（FunctionalReactivationProgramming）开发思想的一种实现。对于React开发，上面说的Flux基本等同于FRP。至于FB之间的功能如何交互，如果处理逻辑简单，不妨直接在相关的FB代码块中编写代码。如果逻辑复杂，不妨以相关FB的公共父节点为入口节点，新建一个FB功能块。取公共父节点的主要作用是父节点可以覆盖其下所有节点从创建到卸载的生命周期，在其idSetter函数中编程会更方便。3、mount数据驱动调试。在可视化设计器开发界面的过程中，可能会出现破坏性重构。比如你在某个FB的入口节点指定数据属性值，然后它的子节点根据数据取值自动生成子节点，如果你给的数据初始值的格式不对，则不会生成子节点。给定的初始值可能是错误的，因为设计改变了，你的数据格式还没来得及调整。为了尽量减少上述破坏性重构带来的错误，在设计接口时，我们建议作为驱动源的数据的初始值取一个“空”值，比如赋值为null或者[]。在界面设计过程中，如果想看看不同的数据初始值会驱动什么样的界面形状，不妨开启W.$dataSrc的定义。比如前面的例子界面默认显示的是摄氏温度格式，因为'.body.calculator.field'节点的scale属性的初始值为'c'，现在我们要检查是否scale='f'接口正确。使用两行代码如下：if(!window.W){window.W=newArray();W.$modules=[];}W.$modules.push(function(require,module,exports){varW=require('shadow-widget');vardataSrc=W.$dataSrc={};dataSrc['.body.calculator.field']={'scale':'f'};});其中vardataSrc=W.$dataSrc={}表示开启W.$dataSrc，默认不开启。还有一句dataSrc['.body.calculator.field']={'scale':'f'}，用来预定义哪个属性的初始值附加到哪个节点上。以上代码可以写成一个独立的js文件。多个这样的js文件可以构建不同的调试场景，然后根据需要使用
