「手淘」研发提效黑科技-行业魔方 | 618 淘系前端技术分享

avatar
前端 @阿里巴巴

作者|玄扈

出品|淘系前端团队

2020年618大促已经过去,作为淘系每年重要的大促活动,淘系前端在其中扮演着什么样的角色,如何保证大促的平稳进行?又在其中应用了哪些新技术?淘系前端团队特此举办了 618 系列征文,为大家介绍 618 中的前端身影。本篇的作者是来自于行业与工作台团队的 玄扈,为大家介绍 行业魔方 项目。

写在前面

过去的一年,笔者在天猫行业支持了成批的行业频道前端建设,深刻体会到业务的发展促使快速建场、高效用场的需求愈发强烈;而行业前端的开发方式仍是劳动密集型,通过加大外包资源投入+玩命加班来完成越来越多的新业务需求,而外包和加班都会导致代码可维护性进一步下降,对频道这类长尾业务弊大于利。

得益于淘系前端的积累,现在我们可以借助完善的天马搭建体系、Rax1.0跨端开发框架、imgcook智能生产这些贼棒的工具完成一个个模块的开发并搭建出一个完整的小程序频道,但在行业这样的生产关系下,我们希望能沉淀出一套更高效的生产体系来支持我们高(hao)效(hao)工(shui)作(jiao)。

去年底开始,天猫行业已与UED、产品团队合作完成了TaoUI组件规范,并建设了织网组件中心来支撑行业沉淀下来的物料,那么,如果按照一定的规范,使用直接的数据模型直接驱动组件,是不是大部分普适的模块就不需要开发了呢?于是,行业魔方项目应运而生。

image.png
image.png

image.png
image.png
image.png
image.png

TL;DR

我们想要 提供一套供行业业务快速搭建出行业页面并高效运营维护的模块生产&使用平台

石器时代

去年底开始推进TaoUI组件落地时,正是行业频道需求的爆发期,我们借此机会沉淀了一批以 行业魔方 为名的通用模块用以支持业务。

image.png
image.png

这批模块成功帮助我们在短期内支持了7个淘宝/天猫行业的频道业务,以及服饰行业新风尚的营销场景混合Feeds需求,有效释放了研发压力。在这批模块中,我们首次引入了数据驱动UI的形式,通过运营在搭建平台配置的数据源DSL来编排数据获取行为,并进行数据与组件物料的组装。

TIC-PFE (1).png
TIC-PFE (1).png

这套方案支持了我们几个月的业务开发,但我们也发现了其中的几个问题:

  1. 运营需要在搭建平台同时配置数据源参数和物料信息,由于schema复杂,操作繁琐,扩展性极差
  2. 随着TaoUI组件的应用持续增加,定制点亦越来越多,我们提出了基于主题进行配置,主题允许业务自行定制,但通用模块不可能透传所有参数到组件
  3. 现有方案的数据获取基于在前端发起请求,在数据源较多或混排规则复杂的场景下性能严重受限
  4. Rax编译时小程序方案不支持动态import组件,通用模块引入业务定制(外部组件)能力实际无法落地

所以,我们决定发展到下个时代~

铜器时代

基于此前在行业魔方通用模块中沉淀的经验,我们决定做出以下几点调整:

  1. 组件基于主题进行配置,主题(元素样式集合)支持业务定制,产出了织网组件配置平台
  2. 与行业后端共建数据链路,将对固定模型DSL的数据源获取、混排、分页等能力在服务端落地,前端模块回归渲染本职
  3. 自建织网模块工坊(行业魔方)平台,用于配置数据源、物料主题,并用于最终发布DSL、生产模块

TIC输出架构 (1).png
TIC输出架构 (1).png

image.png
image.png

这套方案现已小步快跑支持了天猫服饰行业618会场的商品内容混排Feeds流,通过更通用、轻量的方案为营销会场带来了更丰富的体验,让用户不仅买得爽,还能看得爽。

钢铁时代(未来)

行业魔方的能力目前还是较为初级的阶段,我们希望在未来能够通过体系化的建设,帮助业务更快更高效的编排数据->生产出符合规范且有调性的频道模块,一步到位,从而高效支持频道快速建场、频繁迭代的需求场景。

行业魔方.png
行业魔方.png

同时,这套方案因为完全依靠编排数据和物料来渲染频道模块,在基于数据进行物料的混排、对不同种类的数据、不同的物料进行AB等精细化运营场景下,具备天然的接入优势,可以完美实现算法控制数据,数据决定UI。这一理念已在天猫服饰的内部数据平台基于行业魔方的方案有所落地。

行业魔方从0到0.1,离不开相关同学的支持,在此感谢大家!!

本次淘系前端 618 系列预计 7 篇,涵盖淘系前端 618 中的互动、性能、多媒体、PHA、防资损、晚会P2C、智能UI、店铺小程序、行业魔方等内容。

本次 618 系列其他文章:

欢迎关注「淘系前端团队」公众号持续订阅。

扫码_搜索联合传播样式-标准色版