前言上一篇文章讲解了逻辑和Runtime&DSL，也提到了逻辑编排的三招：Components+Arranger+Runtime，我会本篇讨论主要讨论YOHO的组件化设计和平台化。组件在我们的设计中，组件分为基础组件和业务组件。业务组件就是我们需要创建仓库，编写源码，提交发布的组件。它们是逻辑片段的实体；其他一切都是基本组件。我们在专为好莱坞使用而设计的编程方案中。基础组件只有起始组件和结束组件，只是为了降低非开发者的使用成本，组件越少越好。虽然分为基础组件和业务组件，但业务组件本质上是基础组件的一种特殊类型。它们的关系类似于树和图。树也是一种图形，但书籍通常被分成不同的部分。一章，因为树系统够大。业务组件也是如此。它是基础组件中的Custom组件，但是它在组件体系中的比重足够大，所以我们也将其提取为一个大类。组件语言业务组件的几个重要属性如下：初始化业务组件后，我们定义文件结构：.|--schema||--输入.json||--输出.json|`--branch.json|--index.js|--package.jsonindex.js：组件的入口文件，源代码写在里面，文件中的源代码会存储为code字段发布时package.json：从中读取组件的依赖，作为组件的依赖存储起来，与code字段结合使用。input.json：配置组件排列时渲染属性表的JSONSchema，存储为组件的输入字段。output.json：用于描述组件的返回值，也就是JSONSchema，作为组件的输出字段存储。branch.json：描述组件有多少个分支，每个值的中文定义是什么。我们对组件中的分支判断代码制定了规范，配合branch.json，让这个分支类型的业务组件的使用成本降到最低，将使用的复杂度转移到开发的约束上。以《判断是否登录》组件为例。它有两个分支，登录和未登录。分支判断的代码必须写成如下格式：functionfoo(){if(isLogined){return{branch:0,data:{key:value}}}else{return{branch:1,data:{key:value}}}}如果登录，则返回分支值0，如果未登录，则返回分支值1。那么对应的branch.json必须定义如下：['loggedin','notloggedin']元素中返回的branch值将作为branch.json中的索引，元素中实际的分支判断标准必须与branch.json中的相同。数组一一匹配，这样运行时就会按照正确的方向执行逻辑。在组件整体设计的基础工具端，我们提供初始化模板的能力，并提供相应的组件开发脚手架，保证组件的基础开发能力。正在建设中的VSCode插件，用于提升研发体验。基于组件OpenApi的组件SDK可以帮助组件进入组件市场，目前只服务于本地研发，4月份完成开发线上组件的能力。组件的表单配置项借助form-render实现了可视化的表单构建，很好用，点个赞。基于底层设施，上层实现统一的组件市场，按照应用、标签等进行隔离，所有业务组件汇聚到组件市场，方便集成到优酷素材中未来的中心。一个组件的生命一个组件从被生产到被编排，最后运行在页面上，贯穿了逻辑编排的始末，这也是“逻辑是核心”的说法。下面我们从组件的角度来看一下整个逻辑编排的过程。你经历了什么。组件发布后进入组件市场，在布局界面拖拽生成组件实例，构建完整的业务逻辑。在画布中，branch.json用于说明每个分支，并通过form-render将input.json中的jsonschema渲染成可配置的表单。创建布局实例后，它与UI布局相关联。UI构建平台创建的坑，会需要组件的返回值来渲染UI。UI构建平台会解析组件的output.json，将所有数据扁平化展示。.业务模块构建完成后，跟随页面发布上线，启动runtime-->DSL解析-->组件加载&注册-->组件检查-->组件执行链接执行业务相关动作，执行组件中的这一步，会执行runtimeHelper和payload注入，并提供helper函数和配置数据。两个问题下面是我们在落地过程中争论过的两个问题，希望各位评委提出自己的意见。业务元素首先还是结束元素？组件的JSONSchema可以修改吗？具有前端特性的逻辑编排目前在集团内服务编排和业务编排比较多，也有服务端的逻辑编排，但前端侧的逻辑编排很少见。如果你对逻辑编排、业务编排、服务编排不是很清楚，推荐这篇文章——《业务编排、服务编排、逻辑编排的区别》。在落地一个可视化构建系统的过程中，结合构建技术，我们做了一点前端质量实现。在我们的模块构建系统中，每个模块都会生成对应的CDN资源。页面组装时，页面使用的模块资源会在服务端进行拼接——JSCombo。在逻辑编排的过程中，我们不想侵入现有的构建服务，增加开发适配工作，其次，我们也不希望逻辑编排增加页面的JSBundle。所以在runtime的dslWillInterpret生命周期中，我们按需动态加载逻辑元素的资源。组件很小，一个完整流程对应的JS资源只有几KB，这点加载时间可以暂时忽略。结合加载的组件JS资源的缓存复用，进一步减少需要加载的资源量。这个方案帮我们解决了另外一个问题，就是在同一个业务模块中，我会创建多个编排实例，两个编排实例在维护的时候可能会使用同一个组件的不同版本。在这种场景下，如果我们不进行按需动态加载，页面的JSBundle可能会不受控制地快速膨胀。回顾这一点，逻辑组件的按需动态加载帮助我们将页面的逻辑从JSBundle中提取出来，用简单的DSL代替。页面的JSBundle也更小，从而提高了性能。YOHO平台YOHO平台的结构如下。图片最右边是我们YOHO的定位，是一个平台。我们不想做一个完全中心化的平台，我们只是想对协议和规范进行约束，基于这个编排协议做一个统一的节点服务，对外提供OpenApi；在前端交互端，我们并不期望一套交互就可以满足所有的业务，编排器外部框架只会根据编排协议实现各个版块的适配器。您可以选择使用或不使用我们提供的面板或画布，或选择性地使用它们。编排器也将基于此协议实现自动检查和编排快照。.求同存异是我们的选择。在FBP未来的规划中，最后一公里的业务逻辑安排需要提到我们最初的愿景，即YOHO平台搭建平台和服务营销。将业务模块从易到难排列，前75%的模块将按逻辑排列覆盖。剩下的25%包括我们的游戏玩法或高度可定制的模块。它们的共同特点是逻辑要求高，内部状态多。要支持就支持，但是组件调试发布，编排调试发布很麻烦，在我们的预期中，这部分复杂的模块是由研发来承担的。视觉构建中最后一公里的逻辑排列有解决方案吗？是可解的，在现有能力的基础上扩展FBP能力，让研发可以基于流程进行编程，在线编写-->在线测试-->过程纠错，你不仅可以开发得更快，而且你的代码也会更多高效安全。总结一下逻辑编排的价值：可视化：简化业务逻辑UI的制作和逻辑解耦：提高业务模块的可维护性逻辑重用：逻辑可以通过多种不同的方式连接起来，产生不同的行为，会更好其代码重用能力天然是跨终端、跨容器的：因为是纯JS执行的，所以自然适配各个终端、各个容器。其更深远的意义在于，如果UI+逻辑能够覆盖所有模块开发，对于rax0.6转1.0、Weex转Kraken等场景，迁移成本可降低90+%。在线测试和自动纠错：让你的代码更高效安全YOHO的价值：统一大团队中的逻辑布局规范约束方便的工具/库方便逻辑布局在业务中的实现
