我在小程序工程化方面的一些實踐
早期做小程序時，還是原始時代，項目結構混亂，各種冗餘代碼，每次迭代時由於高昂的維護成本，極爲頭疼。遂在一次次的更迭中完成了基礎組件的初版，極爲酸爽。從此之後在當時的情況下只需要關注於業務，對於通用的該封裝封裝，該分層分層，該解耦解耦，也出了一款獨立於業務之外的基礎組件。洋洋自得。
後來入職新公司，遇到的問題也是同樣的，在工作之餘計劃將此前抽象的基礎組件集成進來，發現了不少問題，其中之一就是上手極爲不易，在這個過程中又有一些改進。
更迭
此前公司的小程序開發模式是：
此前的問題對於頁面的創建是極爲的不便，對於代碼的調試也不方便，代碼結構也沒有進行分層。
接入基礎組件之後，目前的小程序優化爲以下結構：
相比之前添加了一層隔離層，好處與未來的規劃可以下圖解釋：
當前小程序此前就採用glup進行構建的，於是我在這個基礎之上添加了一些任務，使用工具自動引入基礎組件，而對編寫上層業務代碼來說是無感知、無侵入的，還可以按照之前的原生方式寫，這是它的一大優勢。
目前還有的問題是頁面之間的Intent通信耦合還是很嚴重，解決思路爲可以提供一箇中介者來完成，不過這個對目前來說問題不大。
目前已經完成的功能有：
- 開發者模式，可以用來切換環境，目前有生產，預發，測試。
- 對App的註冊進行了代理，可以在基礎層完成一些初始化工作。目前有監控的初始化。
- 對每個Page的生命週期與setData方法做了代理，setData在編譯時替換爲了setMFData。
- setMFData目前對setData的調用做了節流。可以提升頁面的渲染性能。
- 將運行時環境所提供的方法掛載到了每個頁面實例下。不需要再通過wx.xx調用，可直接通過this.xx調用。這樣的好處在於使業務代碼與運行時api進行了隔離，也方便使用。
- 對此前的網絡層再做了一層隔離，這一層只是用來承載網絡訪問，並橋接了網絡監控的能力。而上層會做更多的業務處理。
將來可以做的事：
- 可以採用類vue的編寫方式，將4個文件合併至一個文件，擴展名可以爲*.mp。
- 可以寫一個腳手架用來創建*.mp文件。
- 需要寫一個mp-loader將*.mp轉換爲對應的微信文件。
- 可以寫一個轉換工具將之前的代碼合併至一個*.mp文件中。
*.mp文件的結構可以如下：
// *.mp
// <!-- wxml內容 -->
<template>
<view id="page">
</view>
</template>
// <!-- js內容 -->
<script>
Page({
data: {
},
onLoad() {
},
reload() {
},
onUnload() {
}
})
</script>
// <!-- css內容 -->
<style>
#page {
padding: 40rpx 50rpx;
text-align: center;
}
</style>
// <!-- 小程序特有的配置 -->
<config>
{
"navigationBarTitleText": "小程序開發者"
}
</config>
以上就是我目前可以根據當前的一些問題進行的一些探索，這也是一個循序漸進的過程，將來在業務需要時也會催生出更好的方案，權當給大家分享一個實踐的思路。