之前寫了兩篇文章和大家分享了 TienChin 項目中的菜單數據問題，還沒看過的小伙伴請戳這里：

• ??Vue 里，多級菜單要如何設計才顯得專業？??
• ??TienChin 項目動態菜單接口分析??

這兩篇文章主要是和大家說明了后端如何根據當前登錄用戶，動態生成一個菜單 JSON。

那么現在的問題就是，當前端收到后端返回來的菜單 JSON 之后，該如何將之渲染出來？這就是我們目前所面臨的問題了。

TienChin 項目基于 RuoYi 腳手架來完成，所以本文的分析你也可以看作是對 RuoYi-Vue3 項目的分析。

一、整體思路

首先我們來梳理下整體上的實現思路，首先一點：整體思路和 vhr 一模一樣。

考慮到有的小伙伴可能已經忘記 vhr 中前端動態菜單的實現思路了，因此本文再和大家分析一下。

為了確保在所有的 .vue 文件中都能訪問到到菜單數據，所以選擇將菜單數據存入 vuex 中，vuex 是 vue 中一個存儲數據的公共地方，所有的 .vue 文件都可以從 vuex 中讀取到數據。存儲在 vuex 中的數據本質上是存在內存中，所以它有一個特點，就是瀏覽器按 F5 刷新之后，數據就沒了。所以在發生頁面的跳轉的時候，我們應該去區分一下，是用戶點擊了頁面上的菜單按鈕之后發生了頁面跳轉還是用戶點擊了瀏覽器刷新按鈕（或者按了 F5）發生了跳轉。

為了實現這一點，我們需要用到 vue 中的路由導航守衛功能，對于我們 Java 工程師而言，這些可能聽起來有點陌生，但是你把它當作 Java 中的 Filter 來看待就好理解了，實際上我們視頻中和小伙伴們講解的時候就是這么類比的，將一個新事物跟我們腦海中一個已有的熟悉的事物進行類比，就很容易理解了。

vue 中的導航守衛就類似一個監控，它可以監控到所有的頁面跳轉，在頁面跳轉中，我們可以去判斷一下 vuex 中的菜單數據是否還在，如果還在，就說明用戶是點擊了頁面上的菜單按鈕完成了跳轉的，如果不在，就說明用戶是點擊了瀏覽器的刷新按鈕或者是按了 F5 進行頁面刷新的，此時我們就要趕緊去服務端重新加載一下菜單數據。

整體上的實現思路就是這樣，接下來我們來看看一些具體的實現細節。

二、實現細節

1. 加載細節

首先我們來看看加載的細節。

小伙伴們知道，單頁面項目的入口是 main.js，路由加載的內容在 src/permission.js 文件中，該文件在 main.js 中被引入，src/permission.js 中的前置導航守衛內容如下：

router.beforeEach((to, from, next) => {
  NProgress.start()
  if (getToken()) {
    to.meta.title && useSettingsStore().setTitle(to.meta.title)
    /* has token*/
    if (to.path === '/login') {
      next({ path: '/' })
      NProgress.done()
    } else {
      if (useUserStore().roles.length === 0) {
        isRelogin.show = true
        // 判斷當前用戶是否已拉取完user_info信息
        useUserStore().getInfo().then(() => {
          isRelogin.show = false
          usePermissionStore().generateRoutes().then(accessRoutes => {
            // 根據roles權限生成可訪問的路由表
            accessRoutes.forEach(route => {
              if (!isHttp(route.path)) {
                router.addRoute(route) // 動態添加可訪問路由表
              }
            })
            next({ ...to, replace: true }) // hack方法 確保addRoutes已完成
          })
        }).catch(err => {
          useUserStore().logOut().then(() => {
            ElMessage.error(err)
            next({ path: '/' })
          })
        })
      } else {
        next()
      }
    }
  } else {
    // 沒有token
    if (whiteList.indexOf(to.path) !== -1) {
      // 在免登錄白名單，直接進入
      next()
    } else {
      next(`/login?redirect=${to.fullPath}`) // 否則全部重定向到登錄頁
      NProgress.done()
    }
  }
})

我跟大家捋一下這個前置導航守衛中的思路：

(1) 首先調用 getToken 方法，這個方法實際上是去 Cookie 中拿認證 Token，也就是登錄成功后后端返回給前端的那個 JWT 字符串。

(2) 如果 getToken 方法有返回值，說明用戶已經登錄了，那么進入到 if 分支中，如果 getToken 沒拿到值，說明用戶未登錄，未登錄的話，又分為兩種情況：i：訪問的目標地址處于免登錄白名單中，那么此時直接訪問即可；ii：訪問的目標地址不在白名單中，那么此時就跳轉到登錄頁面去，跳轉的時候同時攜帶一個 redirect 參數，這樣方便在登錄成功之后，再跳轉回訪問的目標頁面。這個免登錄訪問的白名單，是一個在 src/permission.js 文件中定義的變量，默認有四個路徑，分別是['/login', '/auth-redirect', '/bind', '/register']。

(3) 如果 getToken 拿到了值，說明用戶已經登錄了，此時又分情況：如果用戶訪問的路徑是登錄頁面，那么就給他重定向到項目首頁（也就是在已經登錄的情況下，不允許用戶再次訪問登錄頁面）；如果用戶訪問的路徑不是登錄頁面，那么首先判斷 vuex 中的 roles 是否還有值？如果有值，說明當前就是用戶點擊了一個菜單按鈕進行跳轉的，那么直接跳轉就行了；如果沒有值，說明用戶是按了瀏覽器的刷新按鈕或者是 F5 按鈕刷新進行的頁面跳轉，那么此時首先調用 getInfo 方法（位于 src/store/modules/user.js 文件中）去服務端重新加載當前用戶的基本信息、角色信息以及權限信息，然后再調用 generateRoutes 方法（位于 src/store/modules/permission.js 文件中）去服務端加載路由信息，并將加載到的路由信息放入到 router 對象中（前提是這個路由對象不是一個 http 鏈接，就是普通的路由地址）。

這就是動態路由的加載整體思路。

在第三步驟中，涉及到兩個方法，一個是 getInfo 還有一個 generateRoutes，這兩個方法也都比較關鍵，我們再來稍微看下。

2. getInfo

首先這個加載用戶信息的方法位于 src/store/modules/user.js 文件中，換言之，這些用戶的基本信息加載到之后，是存儲在 vuex 中的，如果刷新瀏覽器這些數據就會丟失：

getInfo() {
  return new Promise((resolve, reject) => {
    getInfo().then(res => {
      const user = res.user
      const avatar = (user.avatar == "" || user.avatar == null) ? defAva : import.meta.env.VITE_APP_BASE_API + user.avatar;
      if (res.roles && res.roles.length > 0) { // 驗證返回的roles是否是一個非空數組
        this.roles = res.roles
        this.permissions = res.permissions
      } else {
        this.roles = ['ROLE_DEFAULT']
      }
      this.name = user.userName
      this.avatar = avatar;
      resolve(res)
    }).catch(error => {
      reject(error)
    })
  })
},

方法的邏輯其實倒沒啥好說的，結合服務端返回的 JSON 格式，應該就很好理解了（部分 JSON）：

{
    "permissions":[
        "*:*:*"
    ],
    "roles":[
        "admin"
    ],
    "user":
        "userName":"admin",
        "nickName":"TienChin健身",
        "avatar":"",
    }
}

另外再強調下，之前在 vhr 中，我們是將請求封裝成了一個 api.js 文件，里邊有常用的 get、post、put 以及 delete 請求等，然后在需要使用的地方，直接去調用這些方法發送請求即可，但是在 TienChin 中，腳手架的封裝是將所有的請求都提前統一封裝好，在需要的時候直接調用封裝好的方法，連請求地址都不用傳遞了（封裝的時候就已經寫死了），所以小伙伴們看上面的 getInfo 方法只有方法調用，沒有傳遞路徑參數等。

3. generateRoutes

generateRoutes 方法則位于 src/store/modules/permission.js 文件中，這里值得說道的地方就比較多了：

generateRoutes(roles) {
  return new Promise(resolve => {
    // 向后端請求路由數據
    getRouters().then(res => {
      const sdata = JSON.parse(JSON.stringify(res.data))
      const rdata = JSON.parse(JSON.stringify(res.data))
      const defaultData = JSON.parse(JSON.stringify(res.data))
      const sidebarRoutes = filterAsyncRouter(sdata)
      const rewriteRoutes = filterAsyncRouter(rdata, false, true)
      const defaultRoutes = filterAsyncRouter(defaultData)
      const asyncRoutes = filterDynamicRoutes(dynamicRoutes)
      asyncRoutes.forEach(route => { router.addRoute(route) })
      this.setRoutes(rewriteRoutes)
      this.setSidebarRouters(constantRoutes.concat(sidebarRoutes))
      this.setDefaultRoutes(sidebarRoutes)
      this.setTopbarRoutes(defaultRoutes)
      resolve(rewriteRoutes)
    })
  })
}

首先大家看到，服務端返回的動態菜單數據解析了三次，分別拿到了三個對象，這三個對象都是將來要用的，只不過使用的場景不同，下面結合頁面的顯示跟大家細說。

(1) 首先是調用 filterAsyncRouter 方法，這個方法的核心作用就是將服務端返回的 component 組件動態加載為一個 component 對象。不過這個方法在調用的過程中，后面還有兩個參數，第二個是 lastRouter 在該方法中并無實質性作用；第三個參數則主要是說是否需要對 children 的 path 進行重寫。小伙伴們知道，服務端返回的動態菜單的 path 屬性都是只有一層的，例如一級菜單系統管理的 path 是 system，二級菜單用戶管理的 path 則是 user，那么用戶管理最終訪問的 path 就是system/path，如果第三個參數為 true，則會進行 path 的重寫，將 path 最終設置正確。

(2) 所以這里的 sidebarRoutes 和 defaultRoutes 只是能用于菜單渲染（因為這兩個里邊的菜單 path 不對），而最終的頁面跳轉要通過 rewriteRoutes 才可以實現。

(3) 除了服務端返回的動態菜單，前端本身也定義了一些基礎菜單，前端的基礎菜單分為兩大類，分別是 constantRoutes 和 dynamicRoutes，其中 constantRoutes 是固定菜單，也就是一些跟用戶權限無關的菜單，例如 404 頁面、首頁等；dynamicRoutes 是動態菜單，也就是也根據用戶權限來決定是否展示的菜單，例如分配用戶、字典數據、調度日志等等。

(4) filterDynamicRoutes 方法則是將前端提前定義好的 dynamicRoutes 菜單進行過濾，找出那些符合當前用戶權限的菜單將之添加到路由中（這些菜單都不需要在菜單欄渲染出來）。

(5) 接下來涉及到四個不同的保存路由數據的變量，分別是 routes、addRoutes（經松哥分析，這個變量并無實際作用，可以刪除之）、defaultRoutes、topbarRouters 以及 sidebarRouters，四個路由變量的作用各有不同：

routes：

routes 中保存的是 constantRoutes 以及服務端返回的動態路由數據，并且這個動態路由數據中的 path 已經完成了重寫，所以這個 routes 主要用在兩個地方：

(1) 首頁的搜索上：首頁的搜索也可以按照路徑去搜索，所以需要用到這個 routes，如下圖：

(2) 用在 TagsView，這個地方也需要根據頁面渲染不同的菜單，也是用的 routes：

sidebarRouters：

這個就是大家所熟知的側邊欄菜單了，具體展示是 constantRoutes+服務端返回的菜單，不過這些 constantRoutes 基本上 hidden 屬性都是 false，渲染的時候是不會被渲染出來的。

topbarRouters：

這個是用在 TopNav 組件中，這個是將系統的一級菜單在頭部顯示出來的，如下圖：

一級菜單在頂部顯示，左邊顯示的都是二級三級菜單，那么頂部菜單的渲染，用的就是這個 topbarRouters。

defaultRoutes：

想要開啟頂部菜單，需要在 src/layout/components/Settings/index.vue 組件中設置，如下圖：

開啟頂部菜單之后，點擊頂部菜單，左邊菜單欄會跟著切換，此時就是從 defaultRoutes 中遍歷出相關的菜單設置給 sidebarRouters。

好了，這就是這四個 routes 變量的作用，老實說，腳手架中這塊的代碼設計有點混亂，沒必要搞這么多變量，等松哥抽空給大家優化下。

generateRoutes 方法最終會返回 rewriteRoutes 變量到前面說的那個前置導航守衛中，最終前置導航守衛將數據添加到 router 中。

菜單的渲染都是在 src/layout/components/Sidebar/index.vue 中完成的，看了下都是常規操作，沒啥好說的。