对于C端业务偏多的公司来说,在增长、运营等各方同学的摧残下永远绕不过去的一个坑就是大量的H5页面开发,它可能是一个下载、需求告知、产品介绍、营销活动等页面。此类需求都有几个明显的缺点:
•开发性价比极低、上线时间紧,每次需要指派单独同学支持。•沟通成本高,而业务逻辑高度相似。•高频次的需求 有句话怎么说来着,世界是"懒人"创造的,当我们烦透了无休止的重复工作时,一些"偷懒"的想法就会蹦出来。对研发而言我们不想花费过多的时间在此类简单重复的工作上;对运营而言他们需要活动更快的迭代、发版,脱离研发的排期等限制;于公司而言节省人力成本就是节省财务成本,更大的提高效率就可以支撑配合更多增长营销策略。
所以从技术赋能业务的角度出发,一套可视化活动编辑系统是每个中大型公司必备的生产利器。
首先让我们来挑几个代表性的页面简单分析一下...
如下图:
先从页面上做个分析:
•图1、3都属于简单的引流下载页•图2、4属于普通活动页•图5无任何交互逻辑,只是单纯的一个静态告知页•图6从页面结构和业务逻辑来说,属于复杂活动页
接下来抛开UI细节层面不谈,对页面进行一个拆解
•图1、3 组合方式 ( 背景图 + 按钮 + [ ios、安卓 ]下载链接 )
•图2、4 组合方式 ( 背景 + 按钮 + 活动规则 + 领券逻辑 )•图5 组合方式 ( 背景 + 活动规则 )•图6 组合方式 ( 背景 + 业务模块 + 活动规则 )
综上分析可见,每个页面由多个小模块构成,可以是基础UI组件,也可以是一个复杂的业务组件,且组合方式多种多样,可以预想到当我们将这些不同组件像组件库那样整合在一起且可以在页面进行可视化的编辑操作时,不同的组件不同的排列即可生成一个全新的活动,就像积木一样拥有无限种可能,开发效率将会大大提高,本文将这两个月鼓捣lego活动可视化搭建系统(以下简称lego)从0到1的心路历程整理出来供各位有相关需求的小伙伴参考,也欢迎大神交流指正。
核心方案
Lego采用Vue框架开发,通过对组件物料进行拆分再统一管理,形成一个可编辑的组件库。JSON schema 来定义组件JSON规范,配合Vue的动态组件特性来实现动态的页面渲染。动态表单用于根据不同组件特性生成对应配置表单。最后打包并优化多页面,每个页面单独配置域名,一个负责内部编辑、一个负责对外展示。通过活动id获取对应活动JSON数据动态渲染在活动展示页面。
渲染流程:
多页面流程:关于最后的活动页面展示除了多页面外其实还有特别多种方案可选,选择最合适自己业务的就好,后边内容会细说这几种展示方案。
关键词:JSON schema、动态渲染、动态表单、组件管理、多页面
技术方案 动态渲染is
如何将不同的组件打散后再重新拼装并渲染在页面上是整个技术方案最核心的点,好在Vue提供了动态渲染组件方案,通过内置组件conpontent,渲染一个“元组件”为动态组件并根据 is 的值,来决定哪个组件被渲染。
props