这篇文章用以陈述现有购物功能的弊端,同时展望下移动端网页模块化的实践前景。分析场景为商品详情页。文章的思想和我之前一篇《评测框架简述》类同,只不过把平台从iOS移到了Web前端。

商品详情页是由Native和WebView组合而成的页面,Native部分包括上部分的轮播器,商品名称和单价销量。Web部分用以展示商品详情,包装信息以及可以跳转到Native的评价标签。 screenshot1

轮播器出于性能考虑用原生实现是可以理解的。但是食品名称单价两栏并不是Web页面就让人诧异了。因为原生实现并没有体现任何优势,反而不利于实时更新。比如我们今天想来个促销,把28.0划掉,旁边写上9.9,这样的事情原生就办不到了。

这些都不是最重要的。

最重要的是下面的静态页面(上图蓝框部分)是以很低效的纯手工方式编写的HTML代码。它存在以下缺点

  1. 低效
  2. 灵活性差,维护成本高
  3. 专业性强,不懂HTML的业务人员没有能力修改

为了将来有更大的发展空间,我们需要抛弃历史的包袱,重新构建新的实现方式。

数据源和模板分离

恰巧我朋友所在的堆糖公司实现了一套模块化的页面配置系统。就是将网页元素分割成一个个模块,每个模块有独立的数据源和展现方式,模块之间灵活组合,由模板引擎负责在浏览器端拼合和填充。最重要的是最终页面的生成是由不同技术的市场和运营的人完成,大大降低使用门槛,提高效果。

数据+模板—>前端模板引擎渲染—>HTML页面

这和由服务器渲染页面类似,只是把渲染过程移到了前端。这样做的好处有许多

  1. 模块之间独立灵活易组合
  2. 数据源和模板复用
  3. 维护成本低
  4. 服务器减少了渲染过程,性能提升
  5. 省流量,服务器只负责返回必要数据源,模块相关代码存放在客户端本地
  6. 使用门槛低,非技术人员也可以通过组合模块生成页面

下图是在这个体系中各个角色所承担的职责。 screenshot2

What to do next?

在这个系统中,所有的数据源都是人工输入的。可以理解为是一个静态模块化系统。那么动态模块化系统是什么样子的呢?我们可以由市场和运营的人来设置一些约束或查询条件,由服务器根据这些条件计算得出相应的数据源。现阶段我们更需要静态模块化的功能,之后再根据需求来决定是否跟进动态的版本。