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

引子

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

从研发痛点到小程序工程

痛点

第一阶段——搭积木

原生的小程序工程和前端工程差别比较远。官方文档也只会教你如何使用小程序的基础语法来开发。业务方时间排期紧，最重要的任务是将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之外的方案在其余不一样客户端上进行业务的开发，能够更好地将咱们的业务进行多端外投。在小程序方向的技术建设上各个团队也容易达成共识和造成共建协力。

外部生态

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