如何设计实现 H5 页面搭建系统 - 数据模型

1. 如何设计实现 H5 ⻚页⾯面搭建数据模型京东京喜前端团队沐童

2. CATALOG ⽬目录 01 MPM 整体介绍 02 数据层⾯面临的痛点 03 ⻚页⾯面模型设计 04 请求模型设计 05 总结

3. 01 MPM 整体介绍

4. 上线服务4年年+，系统迭代超3个版本 Mart Page Maker 累计使⽤用⼈人数1400+，搭建⻚页⾯面1.9w张除⽇日常活动外，承担80+%的⼤大促会场 H5 卖场可视化搭建系统

5. MPM能⼒力力概览搭建物料料丰富 MPM 现有 30+ 个组件、500+ 个模板，业务能⼒力力覆盖商品、导购、营销等多个场景。配置功能强⼤大三端渲染是 MPM 的强⼤大能⼒力力，除此之外，MPM 还⽀支持⻚页⾯面配置 BI 排序、⾃自动化埋点、⾃自动化测试、⻚页⾯面测速等。系统能⼒力力全⾯面 MPM 为⻚页⾯面保驾护航，不不但配备了了流畅的拖拽编辑器器、实时预览和⻚页⾯面健康诊断能⼒力力，还对系统和⻚页⾯面做了了全⽅方⾯面的监控和容灾降级⽅方案。

6. MPM效果展示 2、选择你需要的模板 1、从这⾥里里拖⼀一个组件到预览区

7. MPM效果展示 4、发布⻚页⾯面 3、配置楼层组件属性

8. MPM效果展示

9. MPM系统架构

10. MPM⼯工作流程

11. 02 数据层⾯面临的痛点

12. 解决场景 “ 请求散乱⽆无章⻚页⾯面请求茫茫多，有时候想定位⻚页⾯面中某个请求来⾃自哪个组件，可能得定位半天…… 卖场承载各线业务，接⼝口场景繁杂，如果简 ” 单地将请求交给组件⾃自身各⾃自发起和处理理，维护起来⼗十分麻烦。

13. 解决场景 “ 多余的重复请求某个⻚页⾯面，多个组件都配置了了同⼀一个预约 ID，导致⻚页⾯面发出了了 N 个⼀一模⼀一样的预约状态查询请求…… 缺乏数据请求统⼀一管理理的后果就是，这些⽆无 ” 效的重复请求将严重拖垮你的⻚页⾯面性能。

14. 解决场景 “ 接⼝口压⼒力力⼤大商品接⼝口⽀支持批量量请求，可我们⻚页⾯面中多个商品组件的接⼝口请求并没有合理理聚合，⾛走批量量调⽤用…… 同个⻚页⾯面经常会多次请求同个业务接⼝口，这 ” 对接⼝口服务造成了了⼗十分⼤大的压⼒力力。

15. 解决场景 “ 数据模型多变商品组件下的各个模板，除请求商品之外，有些模板会拉取新⼈人价，有些模板会拉取补贴价…… 组件对应多个模板，每个模板都可能对应了了 ” 不不同的数据模型。

16. 解决场景 “ 三端同构诉求以 Vue 为例例，我们习惯在组件 created 时请求数据，这在客户端渲染时⼗十分完美，但在直 Vue ⽀支持 SSR，但却⽋欠缺对异步数据获取的出场景却完全⾏行行不不通…… 同构⽀支持，为了了适配 MPM 的三端同构，数 ” 据层设计必须考虑这个问题。

17. 定义为⾃自搭建卖场打造的⼀一套⾼高效通⽤用的数据请求解决⽅方案 1 2 3 统⼀一管理理⾃自由组合适配三端维护请求秩序，优化请求性能数据模型即插即⽤用，⾃自由组合为三端同构提供统⼀一的数据请求⽅方案

18. 03 ⻚页⾯面模型设计

19. PageData PageData 是⻚页⾯面的抽象描述层解析引擎 PageData ——————> 真实⻚页⾯面 interface iPageData { pageId: number; ⻚页⾯面级配置 1）⼀一些基础配置，⻚页⾯面级别的请求，如楼层 BI 排序查询在这⾥里里发起。 2）⻚页⾯面对⽤用户身份的要求配置，⽤用户级请求，如⽤用户身份查询在这⾥里里发起。组件级配置包含了了组件楼层的配置，因此这份配置决定了了组件楼层的业务数据获取。 // ⻚页⾯面id ⻚页⾯面配置基础信息配置搜索配置分享配置 pageConfig: { basic: iBasic; search: iSearch; share: iShare; }; // // // // userConfig: { checkNewUser: boolean; }, // ⽤用户配置 // 1）是否需要查询新⼈人 componentConfig: iComData[] // 组件配置 }

20. ComData ComData 是 PageData 的核⼼心部分模板配置指定使⽤用某个模板，引擎将根据这个配置使⽤用相应的组件模板进⾏行行渲染。数据配置楼层配置数据，这⾥里里包含了了组件请求接⼝口所需的参数。组件关系描述了了组件的⽗父⼦子级对应关系。 interface iComData { uid: number; source: string; data: object; styleKey: string; parentUid: number; children: iComData[]; } // // // // // // 组件id 数据源标识组件配置数据组件模板id ⽗父组件id ⼦子组件

21. 04 请求模型设计

22. 数据源及请求优化策略略 - 统⼀一管理理 + ⾃自由组合 -

23. 数据源数据源是请求模型的基本单位，描述了了⼀一类请求动作接⼝口地址 1 每个数据源对应了了⼀一个接⼝口请求后置处理理请求响应后的⼀一些通⽤用的数据处理理逻辑聚合分发策略略描述了了如何对多个同接⼝口请求作请求聚合和响应分发请求前置处理理 2 3 发起请求前的参数组装处理理 4 5 6 ⼊入参校验对⼊入参进⾏行行校验，不不合法⼊入参将不不会发起请求监控统计配置接⼝口监控、统计相关的配置

24. 数据源 // 数据源模型数据源是⼀一个 class，以配置数据为参，实例例化后可以得到⼀一个请求对象。每个数据源都有⾃自⼰己的名称标识，调⽤用层通过指定数据源标识，来选择调⽤用某个数据源。 interface iDataSource { url: string; // 请求地址 params: object; // 请求参数 verify (params: object): boolean; // 参数验证 beforeRequest (config: MPMComConfig): any; // 请求前置处理理 afterResponse (result: any): any; // 请求后置处理理 batch: iBatch; // 聚合分发策略略 monitor: iMonitor; // 监控统计配置 } // 组件/模板直接调⽤用数据源获取「商品」 dataServive.fetch({ source: 'skus', ...data })

25. ⾃自由组合 1 数据源理理应纯粹⽽而专⼀一数据源应该只做⼀一件简单的事，⽐比如请求响应的⼀一些通⽤用处理理，特殊业务逻辑不不应该在数据源中出现。 2 ⾼高级请求模型由数据源组合⽽而成复杂的请求模型可以由多个数据源组合⽽而成，调⽤用层可以直接调⽤用数据源，也调⽤用封装好的⾼高级请求模型。

26. ⾃自由组合 // 商品 + 优惠券请求模型的组合采⽤用最简单灵活的函数调⽤用，这种组织⽅方式对多变的请求模型⼗十分有利利。向上，我们将调⽤用⽅方式对⻬齐，对开发者来说，调⽤用单⼀一数据源还是⾼高级请求模型，没什什么区别。 async skuWithCoupon (data) { // ... const skus = await dataServive.fetch({ source: ‘skus' }); const coupons = await dataServive.fetch({ source: ‘coupon' }); // ... return result; } // 组件/模板间接调⽤用数据源获取「商品+优惠券」 dataServive.fetch({ source: 'skuWithCoupon', ...data });

27. 统⼀一管理理

28. 请求优化策略略避免重复请求依靠⼀一个简单的请求队列列和请求缓存，我们有效避免了了⻚页⾯面内发起重复请求

29. 请求优化策略略请求的聚合分发策略略 interface iBatch { limit: number pack: (actions: Action[]) => Action unpack: (result: any, actions: Action[]) => Record<ActionMd5, ActionData> } 数据源可制定聚合分发策略略，使得 1 同类请求对象在发出前经 pack 合并，响应后经 unpack 拆包分发引擎以队列列收集请求对象，会等到下 2 ⼀一个 Tick 再发起请求，在这个 Tick 中，如果队列列超限，就会提前发起

30. 请求优化策略略合并同类请求每个数据源可定制⾃自⼰己的聚合分发策略略，以此让同类请求合多为⼀一

31. 初态函数 - 三端同构 -

32. 假如不不考虑同构灵魂拷问：前后端渲染有什什么区别？我想把客户端渲染那⼀一套，照搬到直出端，为什什么不不⾏行行？

33. 假如不不考虑同构客户端的渲染流程客户端允许存在多趟渲染，中间以⻣骨架屏占位，渲染与请求没有严格的先后顺序

34. 假如不不考虑同构直出端的渲染流程直出端只有⼀一趟渲染，渲染前要求数据全部到位，所以请求必须在渲染之前完成

35. 假如不不考虑同构结果你直出了了⼀一份⻣骨架屏？如果你把客户端渲染直接搬到直出端，很遗憾，你可能就只能直出⼀一份⻣骨架屏

36. 基于三端同构的请求模型 1 同构的关键在于初态渲染前后端同构的关键就是初态渲染，也就是⻚页⾯面的初始化渲染阶段。 2 补充适配直出端的⽣生命周期 Vue 现有⽣生命周期没有任何⼀一个能够满⾜足直出端的异步数据获取，要实现直出，数据模型就必须补充适配直出渲染的⽣生命周期。 3 三端解析流程应保持统⼀一要实现三端同构，我们还需要规范解析流程，让三端解析渲染流程保持⾼高度统⼀一。

37. 初态函数位于组件⽣生命周期之前的异步函数 interface iMPMComponent { // ... getInitialState (config: MPMComConfig): Promise<MPMComData>; // ... } 1 每个 MPM 组件都有⼀一个初态函数，三端引擎在创建组件实例例前，将先收初态函数以组件配置数据为⼊入参，异集执⾏行行各组件的初态函数，并将函数步返回⽤用于组件初始化渲染的初态数据。 2 的异步返回结果作为组件初始化渲染的数据。

38. 基于三端同构的解析流静态 H5 / ⼩小程序端

39. 基于三端同构的解析流直出端

40. 初态请求优化刁钻场景：主次接⼝口分端渲染我有⼀一个组件，串串联请求了了主、次两个接⼝口，可是次接⼝口内容没那么重要，为了了提⾼高直出效率，能不不能只直出主接⼝口，次接⼝口等到了了客户端再请求呢？

41. 初态请求优化主次接⼝口数据的分端请求渲染主次接⼝口串串联时，主接⼝口在直出端完成，次接⼝口在客户端补充，提⾼高直出速度 interface iMPMComponent { // ... getInitialState (config: MPMComConfig, callback: (data: MPMComData) => boolean): void; // ... } 1 初态函数的第⼆二个参数是⼀一个回调对于这类初态函数，直出端只会响应函数，传⼊入初态数据并执⾏行行可以触第⼀一个 callback，余下的 callback 将发引擎⽴立刻渲染，因此，利利⽤用它可以实现初态数据的分段渲染。 2 直接忽略略，等到了了客户端之后再作执⾏行行，补充初态数据。

42. 05 总结

43. 01 相⽐比独⽴立开发⼀一个⻚页⾯面，搭建场景开发可能随处都要求着严 02 数据模型解决⽅方案更更多只是⼀一套开发范式，没有规范约束的 03 独⽴立和统⼀一并不不⽭矛盾，虽然搭建的⽬目的是⾃自由组合，但在设谨的设计，任何你认为的微不不⾜足道都不不应该被忽视搭建系统是不不可维护的计开发时却必须⾜足够重视统⼀一的思想

44. THANKS 感谢您的观看欢迎关注我们

45.