前言
前一篇文章里解说了逻辑与 Runtime&DSL，也提到了逻辑编排三板斧：元件 + 编排器 + Runtime，我在本篇将次要聊一聊元件设计以及 YOHO 的平台化。
元件
元件在咱们的设计中，分为根底元件和业务元件，业务元件就是咱们须要创立仓库、编写源码、提交公布的的元件，它是逻辑片段的实体；除它以外的都是根底元件，咱们在设计给好莱坞应用的编排计划中。根底元件只有开始元件和完结元件，只是为了升高非研发人员的应用老本，元件越少越好。
尽管分成了根底元件和业务元件，但业务元件本质上是一种非凡类型的根底元件，它们的关系相似于树和图，树也是图的一种，但书里经常会把书拆成独自的一个章节，因为树的体系足够大。业务元件也是，它就是根底元件中的 Custom 元件，但在元件体系中它的比重足够大，所以咱们也将它抽出来作为一个大类来讲。
元件语言
业务元件的几个重要属性如下：
初始化业务元件后，咱们定义的文件构造：
.
|-- schema
| |-- input.json
| |-- output.json
| `-- branch.json
|-- index.js
|-- package.json- index.js: 元件的入口文件，源码就写在外面，公布时文件中的源码会被作为 code 字段进行存储
- package.json: 元件的 dependency 就是从外面读取，作为元件的依赖项进行存储，和 code 字段配合应用
- input.json: 配置元件编排时渲染属性表单的 JSON Schema，作为元件的 input 字段进行存储
- output.json: 用于形容元件的返回值，同样为 JSON Schema，作为元件的 output 字段进行存储
- branch.json: 形容元件有几个分支，以及每种值的中文定义是什么
咱们对元件中分支判断的代码制订了标准，配合 branch.json，将这种分支型业务元件的应用老本降到了最低，应用的复杂度转嫁为开发的约束性。拿《判断是否登录》元件举例，它有两个分支，已登录 与 未登录，代码进行分支判断是必须依照如下的格局书写：
function foo() {if (isLogined) {return { branch: 0, data: { key: value} }
} else {return { branch: 1, data: { key: value} }
}
}如果已登录，返回 branch 值为 0，如果未登录，返回 branch 值为 1。那么对应的 branch.json 必须如此定义：
['已登录', '未登录']元件中返回的 branch 的值，会作为 branch.json 中的索引，元件中分支理论判断规范要和 branch.json 中的数组一一对应上，这样 runtime 才会依照正确的走向执行逻辑。
元件整体设计
根底工具侧，咱们提供了模板初始化的能力、提供对应的元件开发脚手架，保障元件的根底开发能力，正在建设的 VSCode 插件用于晋升研发体验，基于元件 OpenApi 提供的 元件 SDK 可能帮忙元件录入元件市场，目前还只是服务本地研发，4 月会进行线上元件开发的能力补齐。元件的表单配置项借助 form-render 实现了可视化的表单搭建，很好用，点赞。
基于底层设施，下层实现了对立的元件市场，会依照利用、标签等进行隔离，所有业务的元件在元件市场中收敛，不便当前对立落入优酷物料核心。
元件的毕生
一个元件从被生产到被编排，最初在页面被运行，贯通了逻辑编排的始末，也是“逻辑是外围”的论证，上面咱们就以元件的视角来看看整个逻辑编排过程中它都经验了啥。
元件被公布后，进入元件市场，在编排界面，被拖拽生成元件实例，构建残缺的业务逻辑。画布中，branch.json 被用于论述各个分支，input.json 中的 json schema 通过 form-render 渲染为可配置的表单。编排实例创立完后，与 UI 编排进行关联，在 UI 搭建平台中创立的坑位，会须要元件执行后的返回值渲染 UI，UI 搭建平台会解析元件的 output.json，将所有数据平铺展现。业务模块搭建实现后，追随页面公布上线，runtime 通过 启动 –> DSL 解析 –> 元件加载 & 注册 –> 元件查看 –> 元件执行 链路执行业务相干动作，在 元件执行 这一步，runtime 会进行 helper 和 payload 注入，提供帮忙函数以及配置数据。
两个问题
这里有两个问题是咱们落地过程中争执过的点，也心愿各位看官提出本人的见解。
- 先是业务元件 还是 完结元件？
- 元件的 JSON Schema 能够被批改吗？
前端特色的逻辑编排
团体内目前还是服务编排和业务编排比拟多一点，也有服务端的逻辑编排，前端侧的逻辑编排却不多见。如果你对逻辑编排、业务编排、服务编排不是很分明，举荐这篇文章 ——《业务编排、服务编排、逻辑编排的区别》。在落地可视化搭建零碎的过程中，联合搭建技术咱们做了一点比拟前端质的实现。
咱们的模块搭建零碎，每个模块都会生成对应的 CDN 资源，页面组装的时候，会将页面用到的模块资源在服务端进行拼接 —— JS Combo。在逻辑编排落地的过程中，咱们一不心愿入侵现有构建服务，减少开发适配工作，第二也不心愿逻辑编排增大页面 JS Bundle。所以在 runtime 的 dslWillInterpret 生命周期里，咱们进行逻辑元件的资源按需动静加载。元件都很小，一个残缺的流程对应的 JS 资源只有几 KB，这一点加载工夫暂可疏忽。配合上对已加载元件 JS 资源进行缓存反复利用，须要加载的资源体积会进一步缩小。
这个计划帮忙咱们解决了另一个问题，就是同一个业务模块中，我会创立多个编排实例，两个编排实例可能会在保护过程中呈现应用同一个元件的不同版本，这种场景下，如果咱们不进行按需动静加载，页面的 JS Bundle 可能会不可控地急速扩充。此时回头看，按需动静加载逻辑元件，帮忙咱们将页面的逻辑从 JS Bundle 中抽离了进来，替换成了简洁的 DSL，页面的 JS Bundle 也变小了，对于性能还有晋升。
YOHO 平台
YOHO 平台的构造如下。
在图的最右侧，有咱们对 YOHO 的定位，它是一个平台。咱们不心愿做齐全中心化的平台，咱们只想束缚协定、标准，基于这套编排协定做对立的 node 服务，对外提供 OpenApi；在前端交互侧，不奢求一套交互能够满足所有业务，编排器的外框架只会基于编排协定实现各个板块的适配器，你能够抉择用或者不必咱们提供的面板或者画布，或者选择性的用，编排器同样会基于这套协定去实现主动查看、编排快照等能力。
求同存异是咱们的抉择。
将来布局
FBP，业务逻辑编排最初一公里
这就须要提到咱们当初做 YOHO 平台，要服务营销搭建平台的愿景了。将业务模块从易到难进行排列，后面 75% 的模块将由逻辑编排来笼罩。剩下的 25% 蕴含了咱们的玩法类的或者定制性极强的模块，它们独特特点的逻辑要求高，外部状态多，想反对，也能反对，但元件调试公布、编排调试公布显得极为麻烦，在咱们的预期中，这部分简单模块是由研发来承接的。
可视化搭建中逻辑编排的最初一公里还有解法吗？是可解的，基于现有能力去扩大 FBP 能力，让研发可能基于流来编程，在线编写 –> 在线测试 –> 流程纠错，你不仅能够更快的开发，而且你的代码会更加平安。
总结
逻辑编排的价值：
可视化：简化了业务逻辑的生产
UI 与逻辑解耦：进步业务模块的可维护性
逻辑复用：逻辑能够通过连贯为多种不同的形式来产生不同的行为，会更好的代码复用能力
人造跨端、跨容器：因为是纯 JS 执行，人造适配各端、各容器内。它的更深远意义是，如果 UI + 逻辑可能笼罩所有模块开发，对于 rax0.6 升 1.0、Weex 切 Kraken 这种场景，迁徙老本能够升高 90+%
在线测试、主动纠错：让你的代码更平安
YOHO 的价值：
对立大团队内的逻辑编排标准束缚
便捷的工具 / 库便于逻辑编排在业务中落地