背景交待
NJ 項目啓動初期,團隊技術棧主要是基於 Vue,技術選擇上就選擇了類 Vue 的 wepy。迭代幾個版本後 mpvue 出來了,簡單調研了下,準備基於 mpvue-simple 開發部分頁面,如果可行再慢慢切換其它頁面,嘗試後遇到一些問題,就暫時擱置了,還是沿用的 wepy 繼續開發。
Taro 初現
在不久之後 Taro 橫空出世,按照團隊的情況簡單對比了一下 wepy、mpvue、taro、原生組件開發。
LB 項目初期的情況是有一部分 wepy 沉澱,但是基本可以擺脫歷史包袱,重新啓動新業務項目,對於項目本身僅僅是一個活動小程序項目,不會做多端情況的考慮,在技術選擇上因爲各個技術方案基本解決的問題是多端開發以及在開發過程的舒適度上的提升。對於團隊目前的情況來看,在幾個小夥伴一起討論後,還是基於 wepy 的方案來開發。
如何遷移 Taro 到 Wepy
NJ 項目本身還是基於 wepy,在迭代功能的時候,產品提出要做一個活動頁面,這個活動可能在商城小程序中也會使用到,然後 NJ 繼續迭代功能,需要考慮的是怎麼複用商城項目組開發好的活動頁面(商城項目基於 taro)。
- 跳轉到商城小程序參加活動 [pass]
- 拷貝活動頁面編譯後的文件到 wepy 中直接使用 [cool]
如圖,上述文件以及不需要的頁面均可以直接刪除,然後配置路由到 wepy project 的 app.json 。實際可能也有一些父級邏輯放置在 app.js 中,這個看自己的業務情況來定,我們項目還引入來 dva ,在 wepy 的 app.js 中增加來一個處理 dva 的文件。這個遷移過程總體來說簡單容易很多,暫時不做過多描述。
如何遷移 Wepy 到 Taro
爲來更爲簡單的遷移,這中間寫了一個插件來處理公共業務,對於業務邏輯可以在回調中單獨處理,具體可以參考 wepy-plugin-migratetotaro
NJ 項目經過長期迭代在線上穩定運行。同時另外一條業務線是基於 Taro 開發,也在瘋狂開發迭代中。起因一次活動,XX 項目開發活動內容,NJ 項目正常需求開發,但是開發上線時需要複用 XX 項目開發好的活動頁面。
由於 Wepy2 目前仍處於 alpha ,1.7.x 在開發中也遇見了不少的問題。問題雖然最終都能解決,而且作者很好溝通,諮詢過幾次問題也都能耐心指導解答,筆芯感謝。
再說項目實際情況,在遷移後要保證脫離 Taro 相關項目 Wepy 獨立編譯能夠正常運行。
目錄結構約定
- Taro
- src
- Wepy
- src
代碼管理在 taro project 以子模塊的形式管理 wepy project
git submodules
# 添加子模塊項目
> git submodule add <taro project url>
# 初始化本地 .gitmodules 文件
> git submodule init
# 同步遠端 submodule 源碼
> git submodule update
.gitmodules 示例
[submodule <submodule_name>]
path = <local_directory>
url = <remote_url>
branch = <remote_update_branch_name>
遷移過程
默認配置 wepy 編譯後的目錄(這裏建議配置到 taro 編譯目錄同級目錄下的子目錄。下文均以 Taro 編譯目錄 dist 爲例,wepy 編譯到 dist/wepy 目錄下)
- 編譯目標路徑配置 wepy.config.js target
-
安裝插件 wepy-plugin-migratetotaro (待開發整理髮布)
- 加載機制 require('app.js') $instance (BASE)
- 頁面自動配置所有,可以手動配置需要引入的 pages,但是編譯還是會編譯所有的,編譯過程不可控。暫時部分頁面引入控制略有問題,這裏建議開發過程中以頁面爲維度來管理頁面資源,編譯後不需要的頁面可以手動刪除。
- 路由處理 頁面路徑配置按照編譯路徑最後一級文件夾自動更新引入路徑中的 pages 的跳轉路徑 (BASE)
- 所有路徑添加到子模塊路由中或者主模塊中 路由配置兩種模式,pages 模式 和 subPackages/pages 模式。對應的配置位置不一致,這一點由插件編譯處理。
- taro 組件在 wepy 中使用,在配置中新增 needComponents 配置需要使用組件的組件和頁面。
遷移過程中問題分析
① annot read property '$pages' of undefined
// 頁面初始化的時候 $createPage 中 this.$instance 不存在
if (typeof pagePath === "string") {
this.$instance.$pages["/" + pagePath] = page;
}
// this.$instance 來源於 $createApp
let app = new appClass();
if (!this.$instance) {
app.$init(this, appConfig);
this.$instance = app;
this.$appConfig = appConfig;
}
// appClass 來源於參數 對應 app.wpy
// 如果頁面要單獨執行必須加載一下 app.wpy 但是插件處理的是編譯後的文件,這裏只能在每個頁面 page 中單獨加入 require(wepy/app.js)
② 資源引用,建議圖片視頻等資源使用相對路徑引用,如果項目已有絕對資源路徑可以通過插件回調手動替換處理
③ Taro 組件共享,見後續 taro 組件共享使用方法
如何在 wepy 中使用 taro 寫的組件
這種略待代碼侵入的感覺,可以使用環境變量來處理,只是使用遷移編譯時才生效插件的引入。我們使用插件引入這種是在自定義底部 tabbar 後有一個頁面需要。
-
wepy page 中引入 taro 項目中的 demo 組件
config = { ... usingComponents: { 'demo': '/components/demo/index' } ... }
-
template 中使用組件
... <demo compid="demo"></demo> ...
-
父頁面向子組件傳遞參數(配合插件配置 needComponents 使用,如果原生小程序或者其它框架需要使用 taro 組件可以使用類似方案)
// 按照實際情況修改 props 和 compId taro.propsManager.set( { ...props }, compId );
思索
wepy taro 解決的問題是什麼?對於我而言。
一部分是追求與團隊當前技術棧相契合的類似方案。
一部分是多端需求(最新的這個小程序是多個產品的數據整合,其中之前一個產品是 H5 對外可能微信小程序不是合適的選擇,一個是小程序,如果統一到一起,後續小程序部分頁面可能也會直接轉 H5,後續還可能數據要整合到已有 APP,如此轉 RN 等也是未來的需求),這一塊是爲以後做的考慮,如若不然還是原生的來的自然。
這中間更多的應該是思考,我們其實只是針對當前的產品選擇一個適合自己的技術方案,不抱着某一種方案自始自終,也不牴觸技術的更新,更多的還是需要在這業務堆積過程中不斷沉澱出一些東西,然後不斷更新自己的知識倉庫,這個纔是接下來自己要堅持完善的部分。