关于springboot:Spring-BootVue3-动态菜单实现思路梳理

对于 Spring Boot + Vue3 的动静菜单，松哥之前曾经写了两篇文章了，这两篇文章次要是从代码上和大家剖析动静菜单最终的实现形式，然而还是有小伙伴感觉没太看明确，感觉不足一个提纲挈领的思路，所以，明天松哥再整一篇文章和大家再来捋一捋这个问题，心愿这篇文章能让小伙伴们彻底搞清楚这个问题。

1. 整体思路

首先咱们来看整体思路。

光说思路大家还是云里雾里，咱们联合具体的效果图来看：

最终菜单显示成果相似上图，我把这里的菜单分为了四类：

有父有子：像系统管理那种，既有父菜单，又有子菜单。
只有一个一级菜单，这种又细分为三种状况：
1. 一般的菜单，点击之后在左边主页面关上某个性能页面。
2. 一个超链接，但不是外链，是一个在以后零碎中关上的内部网页，点击之后，会在左边的主页面中新开一个选项卡，这个选项卡中显示的是一个内部网页（实质上是通过 iframe 标签引入的一个内部网页）。
3. 一个超链接，并且还是一个外链，点击之后，间接在浏览器中关上一个新的选项卡，新的选项卡中展现一个内部链接。

整体上来说，就分为这四种状况。其中 1、2.1、2.3 应该都好了解，2.2 有的小伙伴可能不分明，我给大家截个图看下就晓得了：

四种菜单对应的 JSON 格局别离如下：

有父有子：

{
    "name": "Monitor",
    "path": "/monitor",
    "hidden": false,
    "redirect": "noRedirect",
    "component": "Layout",
    "alwaysShow": true,
    "meta": {
        "title": "系统监控",
        "icon": "monitor",
        "noCache": false,
        "link": null
    },
    "children": [{
        "name": "Online",
        "path": "online",
        "hidden": false,
        "component": "monitor/online/index",
        "meta": {
            "title": "在线用户",
            "icon": "online",
            "noCache": false,
            "link": null
        }
    }, {
        "name": "Job",
        "path": "job",
        "hidden": false,
        "component": "monitor/job/index",
        "meta": {
            "title": "定时工作",
            "icon": "job",
            "noCache": false,
            "link": null
        }
    }]
}

只有一个一级菜单，且一级菜单点击后是一个性能页面：

{
    "path": "/",
    "hidden": false,
    "component": "Layout",
    "children": [{
        "name": "Role",
        "path": "role",
        "hidden": false,
        "component": "system/role/index",
        "meta": {
            "title": "角色治理",
            "icon": "peoples",
            "noCache": false,
            "link": null
        }
    }]
}

只有一个一级菜单，且一级菜单点击之后在以后零碎中一个新的选项卡里关上一个网页：

{
    "name": "Http://www.javaboy.org",
    "path": "/",
    "hidden": false,
    "component": "Layout",
    "meta": {
        "title": "TienChin健身官网",
        "icon": "guide",
        "noCache": false,
        "link": null
    },
    "children": [
        {
            "name": "Www.javaboy.org",
            "path": "www.javaboy.org",
            "hidden": false,
            "component": "InnerLink",
            "meta": {
                "title": "TienChin健身官网",
                "icon": "guide",
                "noCache": false,
                "link": "http://www.javaboy.org"
            }
        }
    ]
}

只有一个一级菜单，且一级菜单点击之后在浏览器关上一个新的选项卡：

{
    "name": "Http://www.javaboy.org",
    "path": "http://www.javaboy.org",
    "hidden": false,
    "component": "Layout",
    "meta": {
        "title": "TienChin健身官网",
        "icon": "guide",
        "noCache": false,
        "link": "http://www.javaboy.org"
    }
}

依据以上四种不同的 JSON，咱们总结出以下法则：

父组件都是 Layout，这里的 Layout 就相当于咱们 vhr 中的 Home 组件，也就是整个页面的框架。
如果想在以后零碎中，新开选项卡关上一个性能项，那么这个菜单项必然有 children，即便 children 中只有一项菜单。
如果菜单项是一个外链，那么这个菜单项就不须要有 children 了。
某种程度上，咱们其实能够将 2、3 归为一类，毕竟 3 只是展现内容的组件固定为 InnerLink，2 则视状况而定。
整体上，能够点击的菜单的 path 都是父菜单的 path + 子菜单的 path，如果菜单项有父有子，那就失常拼接就行了；如果只有一个子菜单，那么父菜单的 path 就是 /；如果是一个外链，那就只有父菜单的 path 了。

好了，这就是动静菜单的整体设计。

2. 前端渲染

接下来咱们再来看一看前端的菜单渲染，前端的动静菜单渲染位于 tienchin-ui/src/layout/components/Sidebar/SidebarItem.vue 文件中：

<template>
  <div v-if="!item.hidden">
    <template v-if="hasOneShowingChild(item.children, item) && (!onlyOneChild.children || onlyOneChild.noShowingChildren) && !item.alwaysShow">
      <app-link v-if="onlyOneChild.meta" :to="resolvePath(onlyOneChild.path, onlyOneChild.query)">
        <el-menu-item :index="resolvePath(onlyOneChild.path)" :class="{ 'submenu-title-noDropdown': !isNest }">
          <svg-icon :icon-class="onlyOneChild.meta.icon || (item.meta && item.meta.icon)"/>
          <template #title><span class="menu-title" :title="hasTitle(onlyOneChild.meta.title)">{{ onlyOneChild.meta.title }}</span></template>
        </el-menu-item>
      </app-link>
    </template>

    <el-sub-menu v-else ref="subMenu" :index="resolvePath(item.path)" popper-append-to-body>
      <template v-if="item.meta" #title>
        <svg-icon :icon-class="item.meta && item.meta.icon" />
        <span class="menu-title" :title="hasTitle(item.meta.title)">{{ item.meta.title }}</span>
      </template>

      <sidebar-item
        v-for="child in item.children"
        :key="child.path"
        :is-nest="true"
        :item="child"
        :base-path="resolvePath(child.path)"
        class="nest-menu"
      />
    </el-sub-menu>
  </div>
</template>

这里波及到几个办法，具体的办法细节我就不贴出来了，次要和大家说下实现思路。

先看整体上，这个菜单要是非暗藏的，暗藏的菜单，那么间接一级菜单及其下的子菜单就都不渲染了。
渲染整体上分两块，下面的 template 次要是渲染只有一个子菜单的状况，也就是第一大节的 2、3、4 三种状况，上面的渲染失常的有父有子的状况，也就是第一大节的菜单 1。
hasOneShowingChild 次要是判断这个菜单项是否只有一个须要渲染的子菜单，如果有多个子菜单，然而大部分都是暗藏，只有一个须要渲染进去，那也算只有一个子菜单，如果一个菜单项都没有子菜单，那也算一个子菜单，只不过这个子菜单就是他本身，对应第一大节第 4 种状况。在判断的过程中，将惟一须要渲染的菜单的数据赋值给 onlyOneChild 变量，那么最终，如果以后菜单项只有一个子菜单，且这个子菜单没有子菜单（或者有子菜单然而子菜单不必显示），并且以后菜单也不是必须要渲染的，那就将 onlyOneChild 的数据渲染进去。
对于一般的有父有子的状况，渲染的时候，通过 el-sub-menu 标签进行渲染，然而留神子项是 sidebar-item，sidebar-item 其实就是以后项！换言之，这里的渲染其实还用到了递归（直到没有 children 的时候完结），这样即使菜单有三级四级五级等等，只有不嫌难看，都是能够渲染进去的。

3. 后端菜单生成

3.1 菜单表

首先咱们来看看菜单表的定义，也就是 sys_menu。

CREATE TABLE `sys_menu` (
  `menu_id` bigint(20) NOT NULL AUTO_INCREMENT COMMENT '菜单ID',
  `menu_name` varchar(50) COLLATE utf8mb4_unicode_ci NOT NULL COMMENT '菜单名称',
  `parent_id` bigint(20) DEFAULT '0' COMMENT '父菜单ID',
  `order_num` int(4) DEFAULT '0' COMMENT '显示程序',
  `path` varchar(200) COLLATE utf8mb4_unicode_ci DEFAULT '' COMMENT '路由地址',
  `component` varchar(255) COLLATE utf8mb4_unicode_ci DEFAULT NULL COMMENT '组件门路',
  `query` varchar(255) COLLATE utf8mb4_unicode_ci DEFAULT NULL COMMENT '路由参数',
  `is_frame` int(1) DEFAULT '1' COMMENT '是否为外链（0是 1否）',
  `is_cache` int(1) DEFAULT '0' COMMENT '是否缓存（0缓存 1不缓存）',
  `menu_type` char(1) COLLATE utf8mb4_unicode_ci DEFAULT '' COMMENT '菜单类型（M目录 C菜单 F按钮）',
  `visible` char(1) COLLATE utf8mb4_unicode_ci DEFAULT '0' COMMENT '菜单状态（0显示 1暗藏）',
  `status` char(1) COLLATE utf8mb4_unicode_ci DEFAULT '0' COMMENT '菜单状态（0失常 1停用）',
  `perms` varchar(100) COLLATE utf8mb4_unicode_ci DEFAULT NULL COMMENT '权限标识',
  `icon` varchar(100) COLLATE utf8mb4_unicode_ci DEFAULT '#' COMMENT '菜单图标',
  `create_by` varchar(64) COLLATE utf8mb4_unicode_ci DEFAULT '' COMMENT '创建者',
  `create_time` datetime DEFAULT NULL COMMENT '创立工夫',
  `update_by` varchar(64) COLLATE utf8mb4_unicode_ci DEFAULT '' COMMENT '更新者',
  `update_time` datetime DEFAULT NULL COMMENT '更新工夫',
  `remark` varchar(500) COLLATE utf8mb4_unicode_ci DEFAULT '' COMMENT '备注',
  PRIMARY KEY (`menu_id`)
) ENGINE=InnoDB AUTO_INCREMENT=3054 DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci COMMENT='菜单权限表';

其实这里很多字段都和咱们 vhr 我的项目我的项目很类似，我也就不反复啰嗦了，我这里次要和小伙伴们说一个字段，那就是 menu_type。

menu_type 示意一个菜单字段的类型，一个菜单有三种类型，别离是目录（M）、菜单（C）以及按钮（F）。这里所说的目录，相当于咱们在 vhr 中所说的一级菜单，菜单相当于咱们在 vhr 中所说的二级菜单。

当用户从前端登录胜利后，要去动静加载的菜单的时候，就查问 M 和 C 类型的数据即可，F 类型的数据不是菜单项，查问的时候间接过滤掉即可，通过 menu_type 这个字段能够轻松的过滤掉 F 类型的数据。小伙伴们想想，F 类型的数据过滤掉之后，剩下的数据不就是一级菜单和二级菜单了，那不就和 vhr 又一样了么！

在 vhr 中，思考到菜单就是只有两级：一级菜单和二级菜单，一级菜单是目录，二级菜单是则是具体的菜单项，没有三级菜单！所以在 vhr 中，查问菜单的时候我间接用了一个一对多的查问，将一级菜单做一的一方，二级菜单做多的一方，这样比拟省事。当然灵便度差一点，所以在 TienChin 我的项目中，这块还是用上了递归。

3.2 菜单接口

当用户登录胜利之后，会主动申请 /getRouters 接口来获取菜单信息，咱们一起来看下：

/**
 * 获取路由信息
 *
 * @return 路由信息
 */
@GetMapping("getRouters")
public AjaxResult getRouters() {
    Long userId = SecurityUtils.getUserId();
    List<SysMenu> menus = menuService.selectMenuTreeByUserId(userId);
    return AjaxResult.success(menuService.buildMenus(menus));
}

这里的查问实际上分为两个步骤：

依据用户 id 查问到所有的菜单信息，这一步的查问实际上是比拟容易的，就单纯的多张表联结在一起，而后过滤出和以后用户相干并且菜单类型为 M 或者 C 的菜单（类型为 F 的示意按钮，就不要了），查问到菜单信息之后，而后进行一个递归操作，将菜单数据的层级排列进去。
menuService.buildMenus 这一步则是将菜单数据专为前端所须要的路由数据。

一共就这两个步骤，咱们来逐个进行剖析。

先来看查问菜单数据。

/**
 * 依据用户ID查问菜单
 *
 * @param userId 用户名称
 * @return 菜单列表
 */
@Override
public List<SysMenu> selectMenuTreeByUserId(Long userId) {
    List<SysMenu> menus = null;
    if (SecurityUtils.isAdmin(userId)) {
        menus = menuMapper.selectMenuTreeAll();
    } else {
        menus = menuMapper.selectMenuTreeByUserId(userId);
    }
    return getChildPerms(menus, 0);
}
/**
 * 依据父节点的ID获取所有子节点
 *
 * @param list     分类表
 * @param parentId 传入的父节点ID
 * @return String
 */
public List<SysMenu> getChildPerms(List<SysMenu> list, int parentId) {
    List<SysMenu> returnList = new ArrayList<SysMenu>();
    for (Iterator<SysMenu> iterator = list.iterator(); iterator.hasNext(); ) {
        SysMenu t = (SysMenu) iterator.next();
        // 一、依据传入的某个父节点ID,遍历该父节点的所有子节点
        if (t.getParentId() == parentId) {
            recursionFn(list, t);
            returnList.add(t);
        }
    }
    return returnList;
}
/**
 * 递归列表
 *
 * @param list
 * @param t
 */
private void recursionFn(List<SysMenu> list, SysMenu t) {
    // 失去子节点列表
    List<SysMenu> childList = getChildList(list, t);
    t.setChildren(childList);
    for (SysMenu tChild : childList) {
        if (hasChild(list, tChild)) {
            recursionFn(list, tChild);
        }
    }
}
/**
 * 失去子节点列表
 */
private List<SysMenu> getChildList(List<SysMenu> list, SysMenu t) {
    List<SysMenu> tlist = new ArrayList<SysMenu>();
    Iterator<SysMenu> it = list.iterator();
    while (it.hasNext()) {
        SysMenu n = (SysMenu) it.next();
        if (n.getParentId().longValue() == t.getMenuId().longValue()) {
            tlist.add(n);
        }
    }
    return tlist;
}
/**
 * 判断是否有子节点
 */
private boolean hasChild(List<SysMenu> list, SysMenu t) {
    return getChildList(list, t).size() > 0;
}

这里一共波及到五个要害办法，咱们来逐个进行剖析：

selectMenuTreeByUserId：这个办法的执行比拟容易，如果以后用户是管理员，那就不必加过滤条件了，间接查问出所有的类型为 M 和 C 的菜单项即可。
getChildPerms：这个办法次要是将后面查问进去的菜单数据进行重组，原本都是一个汇合中的数据，当初在该办法中解决成树状，解决的外围逻辑就是调用 recursionFn 办法将之进行递归。
recursionFn：这是最为要害的递归办法了，首先调用 getChildList 获取以后菜单项的 children，而后将获取到的 children 设置给以后菜单项，最初还要遍历获取到的 children，如果这个 children 也是有子菜单的，则持续调用 recursionFn 办法进行解决。
getChildList：这个是查问某一个菜单的子菜单，这个很容易，如果某一个菜单的 parentId 是以后菜单的 id，那么这个菜单就是以后菜单的子菜单。
hasChild：这个是判断给定的菜单是否有子菜单，这个逻辑就比较简单了。

好啦，这个就是整个的查问逻辑，整体上来说是比拟容易的，就是查问 M 和 C 类型的菜单，而后再做一个递归操作，将菜单数据变成一个树状数据。

然而因为 SysMenu 和前后端所须要的路由数据的字段名称对不上，并且格局参数等都不合乎前端的要求，所以还须要再做一个转换，这就是 menuService.buildMenus 所做的事件了：

/**
 * 构建前端路由所须要的菜单
 *
 * @param menus 菜单列表
 * @return 路由列表
 */
@Override
public List<RouterVo> buildMenus(List<SysMenu> menus) {
    List<RouterVo> routers = new LinkedList<RouterVo>();
    for (SysMenu menu : menus) {
        RouterVo router = new RouterVo();
        router.setHidden("1".equals(menu.getVisible()));
        router.setName(getRouteName(menu));
        router.setPath(getRouterPath(menu));
        router.setComponent(getComponent(menu));
        router.setQuery(menu.getQuery());
        router.setMeta(new MetaVo(menu.getMenuName(), menu.getIcon(), StringUtils.equals("1", menu.getIsCache()), menu.getPath()));
        List<SysMenu> cMenus = menu.getChildren();
        if (!cMenus.isEmpty() && cMenus.size() > 0 && UserConstants.TYPE_DIR.equals(menu.getMenuType())) {
            router.setAlwaysShow(true);
            router.setRedirect("noRedirect");
            router.setChildren(buildMenus(cMenus));
        } else if (isMenuFrame(menu)) {
            router.setMeta(null);
            List<RouterVo> childrenList = new ArrayList<RouterVo>();
            RouterVo children = new RouterVo();
            children.setPath(menu.getPath());
            children.setComponent(menu.getComponent());
            children.setName(StringUtils.capitalize(menu.getPath()));
            children.setMeta(new MetaVo(menu.getMenuName(), menu.getIcon(), StringUtils.equals("1", menu.getIsCache()), menu.getPath()));
            children.setQuery(menu.getQuery());
            childrenList.add(children);
            router.setChildren(childrenList);
        } else if (menu.getParentId().intValue() == 0 && isInnerLink(menu)) {
            router.setMeta(new MetaVo(menu.getMenuName(), menu.getIcon()));
            router.setPath("/");
            List<RouterVo> childrenList = new ArrayList<RouterVo>();
            RouterVo children = new RouterVo();
            String routerPath = innerLinkReplaceEach(menu.getPath());
            children.setPath(routerPath);
            children.setComponent(UserConstants.INNER_LINK);
            children.setName(StringUtils.capitalize(routerPath));
            children.setMeta(new MetaVo(menu.getMenuName(), menu.getIcon(), menu.getPath()));
            childrenList.add(children);
            router.setChildren(childrenList);
        }
        routers.add(router);
    }
    return routers;
}

从这个办法的执行逻辑上咱们能够看到，这里的菜单数据一共分为了四种状况，其实刚好就和咱们第一大节所介绍的状况绝对应。

整体上来看，分支语句里面设置了组件的最根本的属性。三个分支语句：

第一个分支，解决一般的有父有子的状况。
第二个分支，解决第一大节第二种状况。
第三个分支，解决第一大节第三种状况。
如果三个分支都没进去，那就是第一大节的第四种状况，以及各个子菜单的状况了。

好了，基于这样大的思路，再来看各个属性的具体设置，就很容易了。

首先是可见性 hidden，这个没啥好说的。
接下来是菜单的 name 属性，name 属性分为了两种状况：路由的 name 属性是菜单表中的 path 字段值且首字母大写（菜单 1、3、4）；如果在一级菜单中，呈现了一个菜单 C（原本这一级别只有 M），并且还不是外链，那么就设置菜单的 name 为空字符串（相当于此时不须要 name 属性了，对应菜单 2 的状况）。
接下来是路由的 path，设置 path 的时候也分好种状况，松哥对照着代码来和大家说一下：

/**
 * 获取路由地址
 *
 * @param menu 菜单信息
 * @return 路由地址
 */
public String getRouterPath(SysMenu menu) {
    String routerPath = menu.getPath();
    // 内链关上外网形式
    if (menu.getParentId().intValue() != 0 && isInnerLink(menu)) {
        routerPath = innerLinkReplaceEach(routerPath);
    }
    // 非外链并且是一级目录（类型为目录）
    if (0 == menu.getParentId().intValue() && UserConstants.TYPE_DIR.equals(menu.getMenuType())
            && UserConstants.NO_FRAME.equals(menu.getIsFrame())) {
        routerPath = "/" + menu.getPath();
    }
    // 非外链并且是一级目录（类型为菜单）
    else if (isMenuFrame(menu)) {
        routerPath = "/";
    }
    return routerPath;
}

a. 首先获取从数据库中查问到的 path 属性。
b. 如果以后组件不是一级菜单，并且是在外部组件中展现，那么除去这个 path 里边的 http 或者 https（对应菜单 3 的 children 的状况）。
c. 如果以后组件是一级菜单并且是 M 型并且不是外链，那么就在原有的 path 上加上 / 前缀（对应菜单 1 的一级菜单的 path 状况）。
d. 如果以后组件是一级菜单，且是 C 型菜单，那么设置 path 为 /（对应菜单 2、3 中一级菜单的 path 状况）。
e. 其余状况，菜单都是从数据库查到什么返回什么。

接下来是设置前端 component，这个菜单项用哪个 component 组件显示进去。

/**
 * 获取组件信息
 *
 * @param menu 菜单信息
 * @return 组件信息
 */
public String getComponent(SysMenu menu) {
    String component = UserConstants.LAYOUT;
    if (StringUtils.isNotEmpty(menu.getComponent()) && !isMenuFrame(menu)) {
        component = menu.getComponent();
    } else if (StringUtils.isEmpty(menu.getComponent()) && menu.getParentId().intValue() != 0 && isInnerLink(menu)) {
        component = UserConstants.INNER_LINK;
    } else if (StringUtils.isEmpty(menu.getComponent()) && isParentView(menu)) {
        component = UserConstants.PARENT_VIEW;
    }
    return component;
}

a. 首先默认的组件是 Layout（菜单1、2、3、4 的一级菜单）。
b. 如果配置的时候就有 component，并且以后菜单项也不是外链，那么就应用配置的 component（菜单 1、2 的子菜单状况）。
c. 如果不是一级菜单（是一个子菜单），并且是一个在以后零碎展现的外链，那么就应用 InnerLink 这个组件（这个组件中有一个 iframe 标签能够把外链展现进去，如菜单 4 的子菜单状况）。
d. 如果配置的时候没有设置组件并且菜单类型是 M（二级菜单中还有三级菜单的状况），那么就设置显示组件为 ParentView。

component 就分为这几种状况。

接下来就是 query 和 meta 这两个参数就没啥好说的。

接下来就是三个分支的状况了。

其余属性都比拟容易，我就不啰嗦啦～

好啦，Vue3+Spring Boot 动静菜单治理，最近整了好几篇了，就先说这么多吧，小伙伴们有问题欢送留言探讨！

关于springboot:Spring-BootVue3-动态菜单实现思路梳理

1. 整体思路

2. 前端渲染

3. 后端菜单生成

3.1 菜单表

3.2 菜单接口

评论

发表回复取消回复

更多文章

DDN HPC 存储硬件架构设计深度分析

探秘IO500：从Lustre并行文件系统出发，开启HPC存储性能新征程

苹果iOS打包的ipa应用无法安装？一篇文章带你了解可能的原因及排查方法

图解Golang：从零开始实现简易版过期LRU缓存

关于springboot:Spring-BootVue3-动态菜单实现思路梳理

1. 整体思路

2. 前端渲染

3. 后端菜单生成

3.1 菜单表

3.2 菜单接口

评论

发表回复 取消回复

更多文章

DDN HPC 存储硬件架构设计深度分析

探秘IO500：从Lustre并行文件系统出发，开启HPC存储性能新征程

苹果iOS打包的ipa应用无法安装？一篇文章带你了解可能的原因及排查方法

图解Golang：从零开始实现简易版过期LRU缓存

发表回复取消回复