探索支付寶小程序：如何與前端工程結合？

引子

「小程序」 在這半年應該是螞蟻最火最熱的詞之一了。小程序的技術棧中，最吸引人的點莫太小程序專屬流量入口了，例如小程序收藏、小程序搜索。在小程序的浪潮之下，不論是螞蟻內部仍是合做企業，都逐步推動業務前端技術棧向小程序看齊。
小程序做爲一個全新的生態，上手開發會和通常的前端技術棧，有很大的差異。那麼小程序又如何和前端工程結合呢？

從研發痛點到小程序工程

痛點

第一階段——搭積木

原生的小程序工程和前端工程差別比較遠。官方文檔也只會教你如何使用小程序的基礎語法來開發。業務方時間排期緊，最重要的任務是將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之外的方案在其餘不一樣客戶端上進行業務的開發，能夠更好地將咱們的業務進行多端外投。在小程序方向的技術建設上各個團隊也容易達成共識和造成共建協力。

外部生態

對於三方開發者，以小程序這樣輕量化的上層應用開發方式，能夠快速地挖掘一批用戶平常的應用，經過這些貼合生活的應用，如「記帳」、「商品掃碼價格查詢」等，來快速地聚合吸引一批用戶。