在我不知道vue的路由還可以通過addRoutes動態(tài)添加時，我只知道vue的路由都是寫死在路由表中的，每當跳轉(zhuǎn)時再去加載相應(yīng)的路由。直到在一個新公司接到需要根據(jù)用戶的權(quán)限顯示不同的菜單的需求時才知道了原來vue-router還有一個addRoutes的API，立馬研究了一下。

router.addRoutes：

函數(shù)簽名：

router.addRoutes(routes: Array<RouteConfig>)

動態(tài)添加更多的路由規(guī)則。參數(shù)必須是一個符合routes選項要求的數(shù)組。

點這里去看router.addRoutes的官方解釋

白話就是需要動態(tài)加入到路由表中的路由是必須要跟我們提前寫死的路由規(guī)則是一樣的。

有了這個玩意兒我們就可以依據(jù)系統(tǒng)管理員給用戶分配的權(quán)限來實現(xiàn)不同的用戶可以進入不同的菜單頁面的功能，是不是很nice？是不是很優(yōu)秀？

但這個還不是本文的重點，本文的重點是“不能將需要動態(tài)添加的路由存入緩存！” 為什么這么說呢？

先說說我們的需求吧。

我們的項目開發(fā)中的動態(tài)路由是提前配好在路由表中的，只是和靜態(tài)路由分開寫在了兩個對象中，導出的時候默認只導出靜態(tài)路由，所謂的靜態(tài)路由就是所有用戶都可以訪問到的公共路由，比如登錄頁面、404頁面等。而不同用戶可訪問不同的菜單頁面是根據(jù)接口返回的一個菜單code來過濾提前配好的動態(tài)路由(提前配好的動態(tài)路由中也有一個code)，再將過濾后的路由使用router.addRoutes動態(tài)添加即可。可能有些公司是通過接口直接把用戶的動態(tài)路由表按照路由的規(guī)則形式給返回了出來，前端只需拿到路由表稍作處理然后addRoutes就可以了。每個公司有每個公司的想法，你開心就好！

接下來就是我們項目中的路由過濾了，這里省略1000字，路由過濾完成并動態(tài)添加后就可以很愉快的訪問菜單頁面了。但我想的是，在全局路由守衛(wèi)中請求接口返回的code（這里接口返回的是一個包含code和其他數(shù)據(jù)的json數(shù)組，所以我還得先把接口返回的code給過濾出來），然后再過濾路由，然后再動態(tài)添加，這對性能來說是一個不小的開銷，所以我就琢磨著能不能把首次過濾好的路由給存在緩存中，這樣下次就可以直接動態(tài)添加緩存中的路由了，豈不是是一件很美好的事情，結(jié)果是我想錯了，你們都想錯了！

來先看看過濾后打印出來的路由吧：

再來看看從緩存中讀出來的路由吧：

從兩張圖上紅色矩形圈圈可以看出，從緩存中讀出來的路由信息已經(jīng)發(fā)生了改變，父路由中的render方法也沒有了（第一張圖中父路由的render方法還是有的，到了第二張就沒有了），且子路由children里邊已經(jīng)沒有了component屬性（從第二張圖中的紅色箭頭處可以看出），這顯然不是我們想要的路由信息。有人說可以使用import xxx from ‘xxx'來替代component的值，這個針對父路由的component都引用了同一個Layout組件來說是可以的，但是子路由呢？從緩存中讀出來的子路由連component都沒有了，即使是有這個屬性，但子路由都引用了不同的component，那你怎么玩？況且將過濾后的路由信息通過緩存的存取來實現(xiàn)，安全上就會有問題，因為如果戶手動修改了緩存里的路由，那你所謂的動態(tài)路由權(quán)限豈不是立馬破功了。

所以，我們能做的就只能是在每次切換路由時都要重新請求接口并根據(jù)返回的code來動態(tài)過濾路由并添加，或者根據(jù)后端返回的動態(tài)路由表直接添加，性能上浪費一點也是沒有辦法的事兒，總比實現(xiàn)不了或不安全來的更好一點。

以上就是本文的全部內(nèi)容，希望對大家的學習有所幫助，也希望大家多多支持腳本之家。

最新評論