引子

“小程式” 在這半年應該是螞蟻最火最熱的詞之一了。小程式的技術棧中，最吸引人的點莫過小程式專屬流量入口了，例如小程式收藏、小程式搜尋。在小程式的浪潮之下，不管是螞蟻內部還是合作企業，都逐步推進業務前端技術棧向小程式看齊。

小程式作為一個全新的生態，上手開發會和一般的前端技術棧，有很大的差別。那麼小程式又如何和前端工程結合呢？

從研發痛點到小程式工程

（一）痛點

（1）第一階段——搭積木

原生的小程式工程和前端工程差異比較遠。官方文件也只會教你如何使用小程式的基礎語法來開發。業務方時間排期緊，最重要的任務是將H5工程遷移至小程式。按照官方文件的只是，用App、Page、Component的方式組織好程式碼，保持整個小程式App純度。此時，小程式的生命週期也侷限於請求資料、處理、展示、互動。

同時，小程式的周邊生態也如雨後春筍一樣迅猛發展。為了確保業務功能快速開發、保證上線，我們在開發過程中快速接入了我們螞蟻國際前端團隊Mock工具——Datahub，也同時接入了阿里巴巴統一的前端監控，確保線上問題可溯源。但是小程式落地方案螞蟻內部各團隊參差不齊，想必在小程式的三方開發者中，這種實現差異化就更加明顯。

（2）第二階段——標準化

在此期間，螞蟻的也在推進小程式標準化的程式，完善了強大的IDE外掛配套，將螞蟻內部開發者和三方開發者的研發流程統一化。螞蟻合作夥伴中的各國的錢包（類似國際版的支付寶），也統一成了全球小程式的標準。

（3）第三階段——工程化

融合了小程式標準之後，開發者也可以向前端工程邁進。讓小程式更貼近團隊前端技術棧。包括對於特定業務模組，可以像Mini-UI一樣，獨立出功能型元件。對於複雜的小程式專案，可建立以SubApp的方式組織小程式工程(見下文)。

（二）小程式工程

為了讓小程式更能貼近日常開發的前端工程模式，下面列出小程式工程所需的一些重要工程配套。

（1）狀態管理

狀態管理使小程式有了資料流，讓小程式真正的“活”起來。最原始的小程式多個Page之間、Page和App之間資料難以共享。藉助狀態管理，Page和App之間的資料可以打通。

在狀態管理中，我們使用herculex。而小程式官方將來也會推出官方的腳手架。如果只是想借助狀態管理而不想讓它管理更新Data，也可以使用Redux和Mobx。只不過萬變不離其宗，小程式使用狀態管理後，結合小程式自身的特性，會有一些神奇的效果。

1.利用頁面保活更新資料

小程式如果兩個Page都開啟過，在一定的時間內兩個頁面都會保活。如果有兩個Page同時監聽一個Store Data，使用者操作，更新了可視頁面Store Data，而在非可視頁面內的Store Data會被靜默更新，觸發渲染。這樣非可視頁面重新出現時，其實使用者已經看到了新的資料來源渲染的頁面。

2.優化更新資料

小程式官方文件中，有提到小程式效能優化，而小程式定製的狀態管理工具herculex已經幫開發者做掉了this.setData操作，開發者不用關心。

（2）Mock方案

我們利用Datahub方案，Mock小程式的底層介面。

Datahub方案，在小程式的IDE開發環境下，可以通過npm  run datahub先啟動Datahub，介面層通過 my.request方式請求到Datahub平臺。

在小程式中使用Datahub有下列幾個優點。

1. 使用Datahub方案，Mock資料來源不會被依賴跟隨構建打包。
2. 場景切換，場景資料可共享，可以一鍵切換任意返回結果。
3. Mock資料可以多人共享。

（3）監控

小程式官方提供了監控的能力，my.reportAnalytics

這對業務來說非常重要，建議在程式碼中加上my.reportAnalytics監控。按照碼以內部的業務經驗來說，需要my.reportAnalytics所需要的地方如下：

1. 介面報錯，try-catch
2. 全域性App onError
3. 關鍵使用者行為，包括重要區塊曝光與點選
4. 其他關鍵業務模組
5. 如果是上報錯誤的話，建議可以採用Error格式上報

（4）國際化

多語言

使用：通過小程式App初始化中取得容器App語言資訊，完成多語言選擇，並保持在全域性資料中。在需要地方，完成語言取用。

（5）擴充套件

元件庫

按照業務的需要，可以自己定義一套類似mini-ui的元件，通過npm包的形式進行復用。

SubApp

針對非常複雜的小程式，想對業務進行隔離但是又有共同的資料，可以將小程式中分割出不同的App模組。用 SubApp的形式來組織。

（三）小程式生態建設

我們將小程式擴充套件到上圖中的生態，基本小程式也能有接近前端工程的能力。

對小程式未來的預測

團隊中很多業務都是基於小程式的，我們團隊認為小程式有以下兩個高潛價值方向。

（一）跨端生態

小程式作為一個統一標準的技術，為各個業務線和各個客戶端上的應用能力互通打下了基礎。理想情況下，一套應用程式碼，可以部署到各個支援標準小程式的客戶端上。能較好地解決目前各個客戶端上技術棧不同導致的壁壘問題。如我們可以使用除H5以外的方案在其他不同客戶端上進行業務的開發，可以更好地將我們的業務進行多端外投。在小程式方向的技術建設上各個團隊也容易達成共識和形成共建合力。

（二）外部生態

對於三方開發者，以小程式這樣輕量化的上層應用開發方式，可以快速地挖掘一批使用者日常的應用，通過這些貼合生活的應用，如“記賬”、“商品掃碼價格查詢”等，來快速地聚合吸引一批使用者。

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/69904796/viewspace-2669941/，如需轉載，請註明出處，否則將追究法律責任。