共计 11979 个字符,预计需要花费 30 分钟才能阅读完成。
对于 Spring Boot + Vue3 的动静菜单,松哥之前曾经写了两篇文章了,这两篇文章次要是从代码上和大家剖析动静菜单最终的实现形式,然而还是有小伙伴感觉没太看明确,感觉不足一个提纲挈领的思路,所以,明天松哥再整一篇文章和大家再来捋一捋这个问题,心愿这篇文章能让小伙伴们彻底搞清楚这个问题。
1. 整体思路
首先咱们来看整体思路。
光说思路大家还是云里雾里,咱们联合具体的效果图来看:
最终菜单显示成果相似上图,我把这里的菜单分为了四类:
- 有父有子:像系统管理那种,既有父菜单,又有子菜单。
-
只有一个一级菜单,这种又细分为三种状况:
- 一般的菜单,点击之后在左边主页面关上某个性能页面。
- 一个超链接,但不是外链,是一个在以后零碎中关上的内部网页,点击之后,会在左边的主页面中新开一个选项卡,这个选项卡中显示的是一个内部网页(实质上是通过 iframe 标签引入的一个内部网页)。
- 一个超链接,并且还是一个外链,点击之后,间接在浏览器中关上一个新的选项卡,新的选项卡中展现一个内部链接。
整体上来说,就分为这四种状况。其中 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 动静菜单治理,最近整了好几篇了,就先说这么多吧,小伙伴们有问题欢送留言探讨!