逻辑编排在优酷可视化搭建中的实践（一） - 逻辑与Runtime

从可视化搭建说起

页面可视化搭建系统从16年开始如雨后春笋般涌现而出，从活动页搭建到中后台搭建，有开源有仅公司内部使用的，都致力于将前端从繁复的体力劳动中解脱出来，提高页面生产效率。优酷内部也有一套营销活动搭建系统，每年生产2K+活动页；能够满足这么多页面的需求，除了沉淀了大量可复用的组件外，围绕着搭建系统的前端研发每天都在不停地维护升级老的组件，同时生产新的组件。

痛点
页面生产能力上去了，研发还是一直埋头在组件开发需求中。这些需要都是从哪里来的呢？其实上面也有提到，就是两点：

老的组件需要添加新的能力，可能是UI改动，可能是逻辑变更
新的业务组件开发
需求是永远也做不完的，为了提高开发效率，研发侧不断地沉淀通用的基础库，与服务端商定标准化的接口，以此来减少维护成本，但基于现有模式锦上添花的优化远远不够。说白了，现有的可视化搭建效率和研发效率都已经达到瓶颈了，我们急需一种新的生产模式，给我们带来生产效率的突破性提升。

解法
我们思考一下，页面可视化搭建是如何解放生产效率的。它将完整的页面进行拆解，拆分为可以复用的组件，研发负责组件生产，产品运营负责组件配置，形成了一种简单的流水线作业的模式，这种模式的好处在于：

业务组件复用，避免重复开发，研发只需要专注于单个组件
产品运营可以介入页面生产过程，减少沟通损耗的同时分担了部分先前研发承担的工作
现在的瓶颈已从页面开发效率转变到组件开发效率上，我们做一个设想，让非研发角色也能介入到组件生产过程中，进一步提高生产效率。在此之前，我们需要先基于现有模式进一步拆分组件结构：

组件可以拆解为 UI + 逻辑。UI 可以通过细粒度的文字、图片、slider等组件搭建出来；逻辑主要涉及到接口请求、数据处理、能力调用，我们将一些常用的api调用比如跳转、常用的接口请求比如查询登录态等进行封装沉淀，加上语义化的描述，非研发人员可以将他们拖拽绘制成流程图，完成业务逻辑的编排。两者结合，就可以生产出完整的业务组件。而对于业务逻辑的组合编排，我们称之为逻辑编排。

举个栗子
我现在有个需求，需要实现一个简单的抽奖活动。页面分为两块，第一块是奖池，五个奖品横铺开，第二块是抽奖按钮，点击按钮，如果用户没登录，拉起登录面板，如果用户已登录，则进行抽奖并高亮展示对应的奖品。

我现在把UI撘出来了，就差逻辑来让对应的坑位展示了，我们把欠缺的逻辑部分拆成两段：

• 进入页面，也就是 componentDidMount 阶段，查询奖池
• 点击抽奖按钮时，查询是否登录，未登录拉起登录面板，已登录则调用抽奖接口