前言：無(wú)論構(gòu)建SPA還是MPA，組件的狀態(tài)是無(wú)法被保存下來(lái)的，這對(duì)于開(kāi)發(fā)過(guò)程中問(wèn)題的重現(xiàn)是比較麻煩的，因?yàn)榭偸菚?huì)失去上下文環(huán)境，導(dǎo)致重現(xiàn)過(guò)程變得繁瑣。于是想到了將Vue Component相關(guān)信息動(dòng)態(tài)綁定在路由上。本文將給出其實(shí)現(xiàn)思路以及相關(guān)問(wèn)題。

場(chǎng)景重現(xiàn)

在使用Vue開(kāi)發(fā)完應(yīng)用后，應(yīng)用上線進(jìn)入了測(cè)試階段。測(cè)試人員測(cè)試出現(xiàn)問(wèn)題后會(huì)對(duì)頁(yè)面進(jìn)行截圖，并將頁(yè)面地址和截圖內(nèi)容發(fā)送給開(kāi)發(fā)人員進(jìn)行bug的確定和修改。這是比較常規(guī)的方式，但這對(duì)開(kāi)發(fā)人員是非常不友好的，因?yàn)殚_(kāi)發(fā)人員拿到的URL地址時(shí)，即沒(méi)有測(cè)試人員的本地?cái)?shù)據(jù)，也需要通過(guò)繁瑣的操作重新按照測(cè)試人員所填寫的內(nèi)容進(jìn)行上下文環(huán)境的重現(xiàn)。為什么我們不能將這些數(shù)據(jù)保存下載，測(cè)試人員將URL發(fā)送給開(kāi)發(fā)人員之后，開(kāi)發(fā)者能很容易定位到上下文環(huán)境并進(jìn)行錯(cuò)誤的重現(xiàn)及調(diào)試。

為什么是URL

無(wú)論你的數(shù)據(jù)是保存在內(nèi)存還是Store，亦或是存放在WebDB中，都會(huì)遇到一個(gè)問(wèn)題：你永遠(yuǎn)都無(wú)法拿到測(cè)試人員的數(shù)據(jù)。那么唯一的方式就是通過(guò)URL來(lái)傳輸數(shù)據(jù)。因此，我們的構(gòu)想是：當(dāng)界面加載組件后，將組件的部分屬性的變化公開(kāi)到URL上，同時(shí)，組件在渲染時(shí)，讀取URL后將值解析還原到組件上去。這樣，即使不斷的刷新頁(yè)面，組件的狀態(tài)也不會(huì)發(fā)生改變。

實(shí)現(xiàn)

于是，我們?yōu)檫@個(gè)功能編寫了一個(gè)Vue插件，取名路由快照（router-snapshot），其實(shí)現(xiàn)代碼如下：

// router-snapshot.js
// https://github.com/dankogai/js-base64
import { Base64 } from 'js-base64';

function beforeRouteEnterHandler (vm, {key, ext}) {
 // 獲取路由綁定字段
 const routeBindKeys = vm.$options[ext] || [];
 // 獲取路由綁定部分的加密字符串
 const routeParamsString = vm.$route.query[key];
 // 解密并轉(zhuǎn)換為JSON
 let routeParamsJSON;
 try {
  routeParamsJSON = JSON.parse(Base64.decode(routeParamsString));
 }catch (e) {
  routeParamsJSON = {};
 }
 routeBindKeys.forEach(attr => {
  // 使用vue的是指方式，若瀏覽器沒(méi)有緩存值，則獲取組件默認(rèn)值
  vm.$set(vm, attr, routeParamsJSON.hasOwnProperty(attr) ? routeParamsJSON[attr] : vm[attr]);
  // 追加屬性反向監(jiān)聽(tīng)，監(jiān)聽(tīng)到的屬性變化都會(huì)呈現(xiàn)在路由上
  vm.$watch(attr, (value) => {
   const query = vm.$route.query;
   let routeSnapshotValueJSON;
   try {
    routeSnapshotValueJSON = JSON.parse(Base64.decode(query[key]));
   }catch (e) {
    routeSnapshotValueJSON = {};
   }
   routeSnapshotValueJSON[attr] = value;
   const extendQuery = {};
   extendQuery[key] = Base64.encodeURI(JSON.stringify(routeSnapshotValueJSON));
   vm.$router.push({
    query: { 
     ...query,
     ...extendQuery
    }
   })
  }, {
   deep: true
  });
 })
}

export default {
 install (Vue, {key = '_', ext = 'routeShot'} = {}) {
  Vue.mixin({
   // beforeRouteEnter (to, from, next) {
   //  console.log('beforeRouteEnter', to, from)
   //  next(beforeRouteEnterHandler)
   // }
   created () {
    beforeRouteEnterHandler(this, {key, ext});
   }
  });
 }
}

代碼邏輯大致如下：

1. 代碼45行，注冊(cè)該組件時(shí)，我們需要指定保存在URL query部分的鍵名，默認(rèn)為_(kāi)；同時(shí)指定綁定在組件上的拓展屬性名，默認(rèn)為routeShot；
2. 代碼21行，根據(jù)組件拓展屬性，對(duì)這些拓展屬性實(shí)施監(jiān)聽(tīng)，將屬性值的變化同步到路由中；
3. 代碼19行，在組件created階段，獲取路由參數(shù)并解析成組件屬性，并將屬性值同步到組件中；
4. 代碼13、25、31行對(duì)路由上的參數(shù)進(jìn)行Base64的加密和解密；

組件的代碼僅僅需要追加routeShot的配置即可：

<template>
  <!-- 使用的iview庫(kù)的Switch組件 -->
  <Switch v-mode="switchValue"></Switch>
</template>
<script>
 export default {
  // 配置routeShot，指定該組件的switchValue屬性映射到URL中
  routeShot: ['switchValue'],
  data () {
   return {
    switchValue: false
   }
  }
 }
</script>

經(jīng)過(guò)這樣，無(wú)論你怎么刷新頁(yè)面，被快照的屬性都不會(huì)發(fā)生改變。另外，除了data屬性，prop、computed屬性也是可以綁定到URL上的。

什么時(shí)候用最適合？

目前來(lái)說(shuō)，應(yīng)用場(chǎng)景中最多的還是非安全性表單以及不需要持久化的數(shù)據(jù)。舉幾個(gè)例子：

1. 表格中篩選項(xiàng)有很多的情況下，用戶進(jìn)行了大量的選擇和填寫操作，結(jié)果因?yàn)榫W(wǎng)絡(luò)原因?qū)е抡?qǐng)求失敗。待網(wǎng)絡(luò)恢復(fù)后，用戶重新刷新頁(yè)面，先前的操作必須重新執(zhí)行；一般情況中，用戶不會(huì)隨意更改瀏覽器的URL，在這種條件下，用戶的刷新不影響上下文的環(huán)境，能給用戶帶來(lái)一定便利；
2. 之前代碼示例中，開(kāi)關(guān)組件的值不交予服務(wù)端進(jìn)行持久化，也是可以使用這種方式來(lái)保存操作的；

存在的問(wèn)題

寫完這個(gè)插件，面臨了三個(gè)我認(rèn)為比較重要的問(wèn)題：

1. 性能問(wèn)題： 通過(guò)代碼47-50行可以看出，早期設(shè)計(jì)是將插件應(yīng)用在路由組件中的，但是在后期的測(cè)試和使用中，發(fā)現(xiàn)還有很多組件不是注冊(cè)在路由中的，也就是父子組件，這樣的組件無(wú)法被路由鉤子攔截到，因此就將該函數(shù)混入到了所有組件的created函數(shù)中。當(dāng)應(yīng)用越來(lái)越大、組件越來(lái)越多的時(shí)候，這個(gè)性能未免有點(diǎn)令人擔(dān)憂；
2. 持久性問(wèn)題： 當(dāng)URL的query部分越來(lái)越大的時(shí)候，超過(guò)了URL的長(zhǎng)度限制，那么組件屬性的持久性將會(huì)被中斷。但我們并不能保證該長(zhǎng)度不會(huì)超過(guò)，這隨著應(yīng)用的增長(zhǎng)是無(wú)法預(yù)料的。在前端中，我們沒(méi)有找到對(duì)應(yīng)的庫(kù)能進(jìn)行定長(zhǎng)加密解密，如果能找到，這個(gè)或?qū)⒈唤鉀Q；
3. 安全性問(wèn)題： 一直找不到比較安全的加密解密方式，而且我覺(jué)得這樣做是會(huì)有安全隱患，但不知道究竟哪種場(chǎng)景會(huì)讓這種安全性問(wèn)題暴露的最大；

以上就是本文的全部?jī)?nèi)容，希望對(duì)大家的學(xué)習(xí)有所幫助，也希望大家多多支持腳本之家。