<>前言

前一篇文章里讲解了逻辑与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的价值:

统一大团队内的逻辑编排规范约束

便捷的工具/库便于逻辑编排在业务中落地

技术
友情链接
码工具
Toolsou
API参考文档
云服务器优惠
阿里云优惠券
腾讯云优惠券
华为云优惠券
站点信息
问题反馈
邮箱:ixiaoyang8@qq.com
QQ群:766591547
关注微信