从可视化搭建说起
页面可视化搭建系统从16年开始如雨后春笋般涌现而出,从活动页搭建到中后台搭建,有开源有仅公司内部使用的,都致力于将前端从繁复的体力劳动中解脱出来,提高页面生产效率。优酷内部也有一套营销活动搭建系统,每年生产2K+活动页;能够满足这么多页面的需求,除了沉淀了大量可复用的组件外,围绕着搭建系统的前端研发每天都在不停地维护升级老的组件,同时生产新的组件。
痛点
页面生产能力上去了,研发还是一直埋头在组件开发需求中。这些需要都是从哪里来的呢?其实上面也有提到,就是两点:
老的组件需要添加新的能力,可能是UI改动,可能是逻辑变更
新的业务组件开发
需求是永远也做不完的,为了提高开发效率,研发侧不断地沉淀通用的基础库,与服务端商定标准化的接口,以此来减少维护成本,但基于现有模式锦上添花的优化远远不够。说白了,现有的可视化搭建效率和研发效率都已经达到瓶颈了,我们急需一种新的生产模式,给我们带来生产效率的突破性提升。
解法
我们思考一下,页面可视化搭建是如何解放生产效率的。它将完整的页面进行拆解,拆分为可以复用的组件,研发负责组件生产,产品运营负责组件配置,形成了一种简单的流水线作业的模式,这种模式的好处在于:
业务组件复用,避免重复开发,研发只需要专注于单个组件
产品运营可以介入页面生产过程,减少沟通损耗的同时分担了部分先前研发承担的工作
现在的瓶颈已从页面开发效率转变到组件开发效率上,我们做一个设想,让非研发角色也能介入到组件生产过程中,进一步提高生产效率。在此之前,我们需要先基于现有模式进一步拆分组件结构:
组件可以拆解为 UI + 逻辑。UI 可以通过细粒度的文字、图片、slider等组件搭建出来;逻辑主要涉及到接口请求、数据处理、能力调用,我们将一些常用的api调用比如跳转、常用的接口请求比如查询登录态等进行封装沉淀,加上语义化的描述,非研发人员可以将他们拖拽绘制成流程图,完成业务逻辑的编排。两者结合,就可以生产出完整的业务组件。而对于业务逻辑的组合编排,我们称之为逻辑编排。
举个栗子
我现在有个需求,需要实现一个简单的抽奖活动。页面分为两块,第一块是奖池,五个奖品横铺开,第二块是抽奖按钮,点击按钮,如果用户没登录,拉起登录面板,如果用户已登录,则进行抽奖并高亮展示对应的奖品。
我现在把UI撘出来了,就差逻辑来让对应的坑位展示了,我们把欠缺的逻辑部分拆成两段:
- 进入页面,也就是 componentDidMount 阶段,查询奖池
- 点击抽奖按钮时,查询是否登录,未登录拉起登录面板,已登录则调用抽奖接口