我在小程序工程化方面的一些實(shí)踐

早期做小程序時，還是原始時代，項(xiàng)目結(jié)構(gòu)混亂，各種冗余代碼，每次迭代時由于高昂的維護(hù)成本，極為頭疼。遂在一次次的更迭中完成了基礎(chǔ)組件的初版，極為酸爽。從此之后在當(dāng)時的情況下只需要關(guān)注于業(yè)務(wù)，對于通用的該封裝封裝，該分層分層，該解耦解耦，也出了一款獨(dú)立于業(yè)務(wù)之外的基礎(chǔ)組件。洋洋自得。

后來入職新公司，遇到的問題也是同樣的，在工作之余計(jì)劃將此前抽象的基礎(chǔ)組件集成進(jìn)來，發(fā)現(xiàn)了不少問題，其中之一就是上手極為不易，在這個過程中又有一些改進(jìn)。

更迭

此前公司的小程序開發(fā)模式是：

此前的問題對于頁面的創(chuàng)建是極為的不便，對于代碼的調(diào)試也不方便，代碼結(jié)構(gòu)也沒有進(jìn)行分層。

接入基礎(chǔ)組件之后，目前的小程序優(yōu)化為以下結(jié)構(gòu)：

相比之前添加了一層隔離層，好處與未來的規(guī)劃可以下圖解釋：

當(dāng)前小程序此前就采用glup進(jìn)行構(gòu)建的，于是我在這個基礎(chǔ)之上添加了一些任務(wù)，使用工具自動引入基礎(chǔ)組件，而對編寫上層業(yè)務(wù)代碼來說是無感知、無侵入的，還可以按照之前的原生方式寫，這是它的一大優(yōu)勢。

目前還有的問題是頁面之間的Intent通信耦合還是很嚴(yán)重，解決思路為可以提供一個中介者來完成，不過這個對目前來說問題不大。

目前已經(jīng)完成的功能有：

• 開發(fā)者模式，可以用來切換環(huán)境，目前有生產(chǎn)，預(yù)發(fā)，測試。
• 對App的注冊進(jìn)行了代理，可以在基礎(chǔ)層完成一些初始化工作。目前有監(jiān)控的初始化。
• 對每個Page的生命周期與setData方法做了代理，setData在編譯時替換為了setMFData。
• setMFData目前對setData的調(diào)用做了節(jié)流。可以提升頁面的渲染性能。
• 將運(yùn)行時環(huán)境所提供的方法掛載到了每個頁面實(shí)例下。不需要再通過wx.xx調(diào)用，可直接通過this.xx調(diào)用。這樣的好處在于使業(yè)務(wù)代碼與運(yùn)行時api進(jìn)行了隔離，也方便使用。
• 對此前的網(wǎng)絡(luò)層再做了一層隔離，這一層只是用來承載網(wǎng)絡(luò)訪問，并橋接了網(wǎng)絡(luò)監(jiān)控的能力。而上層會做更多的業(yè)務(wù)處理。

將來可以做的事：

• 可以采用類vue的編寫方式，將4個文件合并至一個文件，擴(kuò)展名可以為*.mp。
• 可以寫一個腳手架用來創(chuàng)建*.mp文件。
• 需要寫一個mp-loader將*.mp轉(zhuǎn)換為對應(yīng)的微信文件。
• 可以寫一個轉(zhuǎn)換工具將之前的代碼合并至一個*.mp文件中。

*.mp文件的結(jié)構(gòu)可以如下：

// *.mp // <!-- wxml內(nèi)容 --> <template><view id="page"></view> </template>// <!-- js內(nèi)容 --> <script>Page({data: {},onLoad() { },reload() {},onUnload() {}}) </script>// <!-- css內(nèi)容 --> <style>#page {padding: 40rpx 50rpx;text-align: center;} </style>// <!-- 小程序特有的配置 --> <config>{"navigationBarTitleText": "小程序開發(fā)者"} </config>

---

以上就是我目前可以根據(jù)當(dāng)前的一些問題進(jìn)行的一些探索，這也是一個循序漸進(jìn)的過程，將來在業(yè)務(wù)需要時也會催生出更好的方案，權(quán)當(dāng)給大家分享一個實(shí)踐的思路。

總結(jié)

以上是生活随笔為你收集整理的我在小程序工程化方面的一些实践的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。