如何在一個項目中兼容Wepy和Taro？

背景交待

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 等也是將來的需求），這一塊是爲之後作的考慮，如若否則仍是原生的來的天然。
這中間更多的應該是思考，咱們其實只是針對當前的產品選擇一個適合本身的技術方案，不抱着某一種方案自始自終，也不抵觸技術的更新，更多的仍是須要在這業務堆積過程當中不斷沉澱出一些東西，而後不斷更新本身的知識倉庫，這個纔是接下來本身要堅持完善的部分。

參考資料

wepy-plugin-migratetotaro
這是一個不相關的參考資料，能夠微信掃碼瀏覽一下就走