探索支付宝小程序：如何与前端工程结合？

引子

“小程序” 在这半年应该是蚂蚁最火最热的词之一了。小程序的技术栈中，最吸引人的点莫过小程序专属流量入口了，例如小程序收藏、小程序搜索。在小程序的浪潮之下，不管是蚂蚁内部还是合作企业，都逐步推进业务前端技术栈向小程序看齐。
小程序作为一个全新的生态，上手开发会和一般的前端技术栈，有很大的差别。那么小程序又如何和前端工程结合呢？

从研发痛点到小程序工程

痛点

第一阶段——搭积木

原生的小程序工程和前端工程差异比较远。官方文档也只会教你如何使用小程序的基础语法来开发。业务方时间排期紧，最重要的任务是将H5工程迁移至小程序。按照官方文档的只是，用App、Page、Component的方式组织好代码，保持整个小程序App纯度。此时，小程序的生命周期也局限于请求数据、处理、展示、交互。
同时，小程序的周边生态也如雨后春笋一样迅猛发展。为了确保业务功能快速开发、保证上线，我们在开发过程中快速接入了我们蚂蚁国际前端团队Mock工具——Datahub，也同时接入了阿里巴巴统一的前端监控，确保线上问题可溯源。但是小程序落地方案蚂蚁内部各团队参差不齐，想必在小程序的三方开发者中，这种实现差异化就更加明显。

第二阶段——标准化

在此期间，蚂蚁的也在推进小程序标准化的进程，完善了强大的IDE插件配套，将蚂蚁内部开发者和三方开发者的研发流程统一化。蚂蚁合作伙伴中的各国的钱包（类似国际版的支付宝），也统一成了全球小程序的标准。

附：小程序的官方组件库和小程序图表库

第三阶段——工程化

融合了小程序标准之后，开发者也可以向前端工程迈进。让小程序更贴近团队前端技术栈。包括对于特定业务模块，可以像Mini-UI一样，独立出功能型组件。对于复杂的小程序项目，可建立以SubApp的方式组织小程序工程(见下文)。

小程序工程

为了让小程序更能贴近日常开发的前端工程模式，下面列出小程序工程所需的一些重要工程配套。

状态管理

状态管理使小程序有了数据流，让小程序真正的“活”起来。最原始的小程序多个Page之间、Page和App之间数据难以共享。借助状态管理，Page和App之间的数据可以打通。

在状态管理中，我们使用herculex。而小程序官方将来也会推出官方的脚手架。如果只是想借助状态管理而不想让它管理更新Data，也可以使用Redux和Mobx。只不过万变不离其宗，小程序使用状态管理后，结合小程序自身的特性，会有一些神奇的效果。

1. 利用页面保活更新数据

   小程序如果两个Page都打开过，在一定的时间内两个页面都会保活。如果有两个Page同时监听一个Store Data，用户操作，更新了可视页面Store Data，而在非可视页面内的Store Data会被静默更新，触发渲染。这样非可视页面重新出现时，其实用户已经看到了新的数据源渲染的页面。

2. 优化更新数据

   小程序官方文档中，有提到小程序性能优化，而小程序定制的状态管理工具herculex已经帮开发者做掉了this.setData操作，开发者不用关心。

Mock方案

我们利用Datahub方案，Mock小程序的底层接口。

// datahub.config.js
module.exports = {
  port: 5678,
  store: require('path').join(__dirname, 'data'),
}

// package.json
"scripts": {
  "datahub": "datahub server -c datahub.config.js",
},

Datahub方案，在小程序的IDE开发环境下，可以通过npm run datahub先启动Datahub，接口层通过my.request方式请求到Datahub平台。

// request
my.request({
  url: `http://127.0.0.1:5678/data/#你的业务名#/${#你的接口名#}`,
  method,
  data: params,
  dataType: 'json',
  success: res => resolve(res.data),
  fail: (res) => {
    reject(res)
    my.showToast({
      type: 'exception',
      duration: 3000,
      content: 'DataHub 网络异常，请检查 DataHub 配置',
    })
  },
})

在小程序中使用Datahub有下列几个优点。

1. 使用Datahub方案，Mock数据源不会被依赖跟随构建打包。
2. 场景切换，场景数据可共享，可以一键切换任意返回结果。
3. Mock数据可以多人共享。

监控

小程序官方提供了监控的能力，my.reportAnalytics
这对业务来说非常重要，建议在代码中加上my.reportAnalytics监控。按照码以内部的业务经验来说，需要my.reportAnalytics所需要的地方如下：

1. 接口报错，try-catch
2. 全局App onError
3. 关键用户行为，包括重要区块曝光与点击
4. 其他关键业务模块

   如果是上报错误的话，建议可以采用Error格式上报

new Error([message[, fileName[, lineNumber]]])

国际化

多语言

//app.js
my.getSystemInfo({
  success: res => {
    this.globalData.i18n = require(`./i18n/${languageMap[res.language] || 'zh-CH'}.js`)
  },
  fail: () => {
    this.globalData.i18n = require('./i18n/zh-CH.js')
  },
})

//util.js
export function getText (key, defaultValue) {
  return getApp().globalData.i18n[key] || defaultValue || key
}

使用：通过小程序App初始化中取得容器App语言信息，完成多语言选择，并保持在全局数据中。在需要地方，完成语言取用。

扩展

组件库

按照业务的需要，可以自己定义一套类似mini-ui的组件，通过npm包的形式进行复用。

# shell
yarn add mini-program-component

// page.json
"usingComponents": {
  "treasure-card": "mini-program-component/es/treasure-card/index",
}

SubApp

针对非常复杂的小程序，想对业务进行隔离但是又有共同的数据，可以将小程序中分割出不同的App模块。用SubApp的形式来组织。

.
├── README.md
├── app.acss
├── app.js # App
├── app.json
├── package.json
├── store # App Store
│   └── index.js
├── subApp1 # Sub App 1
│   ├── components
│   ├── pages # Page 1
│   └── store # Sub App Store 1
└── subApp2
    ├── components
    ├── pages # Page 2
    └── store  # Sub App Store 2

小程序生态建设

我们将小程序扩展到上图中的生态，基本小程序也能有接近前端工程的能力。

对小程序未来的预测

团队中很多业务都是基于小程序的，我们团队认为小程序有以下两个高潜价值方向。

跨端生态

小程序作为一个统一标准的技术，为各个业务线和各个客户端上的应用能力互通打下了基础。理想情况下，一套应用代码，可以部署到各个支持标准小程序的客户端上。能较好地解决目前各个客户端上技术栈不同导致的壁垒问题。如我们可以使用除H5以外的方案在其他不同客户端上进行业务的开发，可以更好地将我们的业务进行多端外投。在小程序方向的技术建设上各个团队也容易达成共识和形成共建合力。

外部生态

对于三方开发者，以小程序这样轻量化的上层应用开发方式，可以快速地挖掘一批用户日常的应用，通过这些贴合生活的应用，如“记账”、“商品扫码价格查询”等，来快速地聚合吸引一批用户。