vue-router擴展實踐

咱們但願使用vue-router去作什麼？

在最近的項目中，咱們基於vue全家桶創建一個H5 WAP版項目，咱們對該項目有幾點設想：

1. 可以直接嵌入多個APP，做爲Hybrid APP；
2. 簡單化的跳轉；
3. 運營配置通用化。

Hybrid

雖然這是一個H5 WAP項目，但部分頁面會嵌入到APP裏面，同一個頁面H_0的點擊按鈕跳轉須要同時兼容兩種狀況：
WAP: H_0 --> H_1 頁面H_0點擊按鈕跳轉到頁面H_1
Hybird: H_0 --> A_1 頁面H_0點擊按鈕跳轉到APP的A_1模塊

簡單化的跳轉

簡單化，即沒有額外的學習成本就可以使用。目前使用MVVM框架搭建的項目，幾乎都會使用路由庫Router來完成管理頁面的切換，Vue一樣也擁有官方Vue-Router的支持，因此，咱們但願可以保持和Vue-Router的導航API（push、replace、go）一致的調用方式。

運營配置通用化

項目中的模塊跳轉是經過管理後臺配置，例如首頁的九宮格菜單，運營人員會配置不一樣模塊的組合和跳轉地址，在APP裏面，這個跳轉地址是基於schema規則，但在wap端會是基於url或route name來實現，映射關係相似下表：

APP	WAP URL	WAP Route Name
myschema://category?id=1	/h5/page0/category_fun/1	category_fun

在這個狀況下，咱們但願運營人員在知曉schema規則的狀況下就可以完成H5端的配置，因此咱們須要可以兼容schema方式的跳轉。

如何選擇？

開發一套全新的Router庫替換Vue-Router

這個方案從一開始就被排除了，Vue-Router自己已經可以覆蓋到咱們頁面跳轉需求，並且也獲得開源社區的支持，從新開發一套的成本和效果仍是值得好好考慮。

基於Vue-Router進行封裝

保持和Vue-Router相同的API，針對不一樣的環境和地址執行不一樣的流程。

Router Pre Parse 解析跳轉的參數、Url地址、Schema地址以及環境的解析（是否內嵌APP），肯定頁面應該執行Extent-Router或Vue-Router
Extent-Router 實現Schema方式的跳轉
這個方式是代碼耦合度最低的，結構清晰，並且也方便在將來直接替換Vue-Router，但開發成本也不低，Router Pre Parse須要實現類Vue-Router的導航API以及監聽popstate事件以接管Vue-Router的默認行爲，完整解析Vue-Router的規則，簡單來講，就是實現Vue-Router大部分的解析行爲，將Vue-Router弱化成單純的跳轉組件。

基於Vue-Router的beforeEach事件擴展

基於開發成本的考慮，咱們最後採用了這個最簡單的方案。

router.beforeEach((to, from, next) => {
  // ...
})

當一個導航觸發時，beforeEach全局前置守衛按照建立順序調用。守衛是異步解析執行，此時導航在全部守衛 resolve 完以前一直處於 等待中。
前置觸發、等待執行、容許中斷，這是beforeEach提供的三個優點，而自己是Vue-Router的函數又提供給咱們解析跳轉參數、Url的基本功能。咱們也可以基於Vue-Router的導航API直接方便的調用。

實現這樣一套機制，咱們可以實現多種跳轉格式的兼容：

this.$router.push({
    name: category_fun,
    params: {
            id: 1
    }
});

this.$router.push({
    name: 'myschema://category?id=1'
});

this.$router.push({
    name: '/h5/page0/category_fun/1'
});

甚至，在Route Schema映射模塊裏，也實現了彈窗這樣的無跳轉schema，反正next(false)可以中斷導航。

this.$router.push({
    name: 'myschema://justopendialog?data={title:"標題",text:"這是一個彈窗而已"}'
});

總結

這個需求場景具備其特殊性，咱們才須要作這種擴展嘗試，目標已經實現，可是否可靠仍須要在將來繼續踩坑，這裏僅僅是提供一個思路，也許不斷地迭代會讓咱們從beforeEach的方案逐步過分到第二方案甚至重寫一個路由輪子。