引子
“小程式” 在這半年應該是螞蟻最火最熱的詞之一了。小程式的技術棧中，最吸引人的點莫過小程式專屬流量入口了，例如小程式收藏、小程式搜尋。在小程式的浪潮之下，不管是螞蟻内部還是合作企業，都逐漸推進業務前端技術棧向小程式看齊。
小程式作為一個全新的生态，上手開發會和一般的前端技術棧，有很大的差别。那麼小程式又如何和前端工程結合呢？
從研發痛點到小程式工程
痛點
第一階段——搭積木
原生的小程式工程和前端工程差異比較遠。官方文檔也隻會教你如何使用小程式的基礎文法來開發。業務方時間排期緊，最重要的任務是将H5工程遷移至小程式。按照官方文檔的隻是，用App、Page、Component的方式組織好代碼，保持整個小程式App純度。此時，小程式的生命周期也局限于請求資料、處理、展示、互動。
同時，小程式的周邊生态也如雨後春筍一樣迅猛發展。為了確定業務功能快速開發、保證上線，我們在開發過程中快速接入了我們螞蟻國際前端團隊Mock工具——
Datahub，也同時接入了阿裡巴巴統一的前端監控，確定線上問題可溯源。但是小程式落地方案螞蟻内部各團隊參差不齊，想必在小程式的三方開發者中，這種實作差異化就更加明顯。
第二階段——标準化
在此期間，螞蟻的也在推進小程式标準化的程序，完善了強大的IDE插件配套，将螞蟻内部開發者和三方開發者的研發流程統一化。螞蟻合作夥伴中的各國的錢包（類似國際版的支付寶），也統一成了全球小程式的标準。
附：小程式的 官方元件庫 和 小程式圖表庫
第三階段——工程化
融合了小程式标準之後，開發者也可以向前端工程邁進。讓小程式更貼近團隊前端技術棧。包括對于特定業務子產品，可以像Mini-UI一樣，獨立出功能型元件。對于複雜的小程式項目，可建立以SubApp的方式組織小程式工程(見下文)。
小程式工程
為了讓小程式更能貼近日常開發的前端工程模式，下面列出小程式工程所需的一些重要工程配套。
狀态管理
狀态管理使小程式有了資料流，讓小程式真正的“活”起來。最原始的小程式多個Page之間、Page和App之間資料難以共享。借助狀态管理，Page和App之間的資料可以打通。
在狀态管理中，我們使用
herculex。而小程式官方将來也會推出官方的腳手架。如果隻是想借助狀态管理而不想讓它管理更新Data，也可以使用Redux和Mobx。隻不過萬變不離其宗，小程式使用狀态管理後，結合小程式自身的特性，會有一些神奇的效果。
- 利用頁面保活更新資料
小程式如果兩個Page都打開過，在一定的時間内兩個頁面都會保活。如果有兩個Page同時監聽一個Store Data，使用者操作，更新了可視頁面Store Data，而在非可視頁面内的Store Data會被靜默更新，觸發渲染。這樣非可視頁面重新出現時，其實使用者已經看到了新的資料源渲染的頁面。 - 優化更新資料
小程式官方文檔中，有提到[小程式性能優化](https://yq.aliyun.com/go/articleRenderRedirect?url=https%3A%2F%2Fdocs.alipay.com%2Fmini%2Fframework%2Fperformance-tips)，而小程式定制的狀态管理工具herculex已經幫開發者做掉了`this.setData`操作，開發者不用關心。
Mock方案
我們利用
方案，Mock小程式的底層接口。
// datahub.config.js
module.exports = {
port: 5678,
store: require('path').join(__dirname, 'data'),
} // package.json
"scripts": {
"datahub": "datahub server -c datahub.config.js",
}, 方案，在小程式的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有下列幾個優點。
- 使用Datahub方案，Mock資料源不會被依賴跟随建構打包。
- 場景切換，場景資料可共享，可以一鍵切換任意傳回結果。
- Mock資料可以多人共享。
監控
小程式官方提供了監控的能力，
my.reportAnalytics這對業務來說非常重要，建議在代碼中加上
my.reportAnalytics
監控。按照碼以内部的業務經驗來說，需要
my.reportAnalytic
s所需要的地方如下：
- 接口報錯，try-catch
- 全局App onError
- 關鍵使用者行為，包括重要區塊曝光與點選
- 其他關鍵業務子產品
如果是上報錯誤的話，建議可以采用`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以外的方案在其他不同用戶端上進行業務的開發，可以更好地将我們的業務進行多端外投。在小程式方向的技術建設上各個團隊也容易達成共識和形成共建合力。
外部生态
對于三方開發者，以小程式這樣輕量化的上層應用開發方式，可以快速地挖掘一批使用者日常的應用，通過這些貼合生活的應用，如“記賬”、“商品掃碼價格查詢”等，來快速地聚合吸引一批使用者。