陈词滥调了!
尽管咱们是 Java 猿,然而写起来前端代码也不含糊!明天我想来和大家聊聊这个前端的动静菜单,要如何设计才显得业余!还是以咱们的 TienChin 我的项目为例,大家一起来看看。
先来一张截图看看成果:
那么这样的菜单是如何设计进去的呢?
明天我也不想和大家聊过多的技术细节,就聊聊这个路由是如何设计的,一旦大家明确了路由是如何设计的,剩下的问题都是细枝末节的问题了。
1. 路由设计
有的小伙伴做过 vhr,晓得 vhr 里的动静菜单实现形式,松哥和大家一样,也是在一直学习不断进步中,明天我想和大家探讨 TienChin 我的项目中动静菜单的实现计划,看看是否是一种更佳的解决方案。
1.1 菜单设计
先来和小伙伴们回顾下 vhr 中的计划:
在 vhr 中,权限的管制,只管制到二级菜单,也就是一级菜单和权限没关系。举个例子,当初有一级菜单 A 和 二级菜单 B,B 是 A 中的菜单,当初假如:
- 如果以后用户权限能够查看 B 菜单,那么 A 菜单会主动显示进去。
- 如果以后用户权限无奈查看 B 菜单,且 A 菜单中也没有其余子菜单能够展现,那么 A 菜单就不会显示进去。
换言之,A 菜单显示与否,次要看它里边有没有子菜单须要展现,如果有,A 菜单就显示,如果没有,A 菜单就不显示。
vhr 中的思路是这样的。
在 TienChin 我的项目中,这一块有一些变动:
如果 A 中只有一个 B,那么仿佛就没有必要再做一个两级菜单了,间接把 B 展现进去不就行了?用户操作也不便!
这是第一个不一样的中央。
1.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 } }]}]
这里我举了两个菜单的例子,这两个例子比拟具备代表性,这个菜单最终显示成果大略相似上面这样:
系统监控
- 在线用户
- 定时工作
- 角色治理
大略显示成果如上图。
接下来我就来说一下这里几个典型属性:
- redirect:noRedirect 示意该路由在面包屑导航中不可被点击。
- alwaysShow:如果这个属性设置为 false,那么当以后菜单只有一个子菜单的时候,默认状况下就只会显示子菜单,而疏忽父菜单(如 1.1 大节所述),然而如果将该属性设置为 true,则无论以后菜单有几个子菜单,都会将以后菜单展现进去(这就相似于 vhr 中的成果了)。
- 每一个父菜单都有本人的 path,每一个 children 也有本人的 path,父菜单的 path 加上每一个 children 的 path,独特组成每一个 children 的门路。
- 再来看第二个角色治理这个菜单项,因为它的父菜单中只有一个子菜单项,并且父菜单中也没有 alwaysShow 属性,所以这个菜单项在最终展现的时候,就只展现里边的角色治理,父菜单则不会展现进去(正好,生成的 JSON 中也没说父菜单的名字、图标等属性)。
当然,不是说你的 JSON 这么写就主动这么显示,JSON 中的货色只是一个标记,最终怎么显示,还要看渲染:
<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}"> <item :icon="onlyOneChild.meta.icon||(item.meta&&item.meta.icon)" :title="onlyOneChild.meta.title" /> </el-menu-item> </app-link> </template> <el-submenu v-else ref="subMenu" :index="resolvePath(item.path)" popper-append-to-body> <template slot="title"> <item v-if="item.meta" :icon="item.meta && item.meta.icon" :title="item.meta.title" /> </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-submenu></div>
还有一个函数我就没有列出来了,反正咱们看名字也大略晓得每一个函数的含意。
大家看,这个 div 中实际上分为了两局部,下面 template 专门用来解决 children 中只有一项的状况(角色治理),具体解决形式就是把 children 拿进去显示,其余的则不思考,具体执行的时候不肯定是只有一个 children,也有可能压根就没有 children,此时间接显示 parent 即可(参考 1.3 大节)。
上面的 el-submenu 则解决 children 有多个的状况(系统监控)。
另外这里波及到了一个 resolvePath,也是特地要害的一个办法,咱们来大抵看下:
resolvePath(routePath, routeQuery) { if (isExternal(routePath)) { return routePath } if (isExternal(this.basePath)) { return this.basePath } if (routeQuery) { let query = JSON.parse(routeQuery); return { path: path.resolve(this.basePath, routePath), query: query } } return path.resolve(this.basePath, routePath)}
这个函数的次要左右,就是解决菜单的门路问题。
咱们来看下这个具体的判断逻辑:
- 如果这个菜单的门路是一个外链(判断逻辑是查看这个 path 是否有 http 或者 https 等前缀),即 isExternal 返回 true,就把这个门路一成不变返回。
- 如果这个菜单的父菜单的门路是一个外链,则将父菜单的 path 原封不懂返回。
- 如果有查问参数,就把参数加上。
- 最初通过 path.resolve 对门路进行一个简略运算。
有的小伙伴可能对 path.resolve 不相熟,我简略说下:
path.resolve() 办法能够将多个门路解析为一个规范化的绝对路径,它的解决形式相似于对这些门路逐个进行 cd 操作,然而与 cd 操作不同的是,这些门路能够是文件,并且可不用理论存在(resolve() 办法不会利用底层的文件系统判断门路是否存在,而只是进行门路字符串操作)。例如:
path.resolve('foo/bar', '/tmp/file/', '..', 'a/../subfile')
相当于:
cd foo/barcd /tmp/file/cd ..cd a/../subfilepwd
举个简略的例子:
path.resolve('/foo/bar', './baz') // 输入后果为 '/foo/bar/baz' path.resolve('/foo/bar', '/tmp/file/') // 输入后果为 '/tmp/file' path.resolve('wwwroot', 'static_files/png/', '../gif/image.gif') // 以后的工作门路是 /home/javaboy/node,则输入后果为 '/home/javaboy/node/wwwroot/static_files/gif/image.gif'
当初大家晓得菜单跳转的门路是怎么来的了吧!
1.3 外链问题
在 TienChin 我的项目中,菜单还存在一个外链的问题。
这个外链有两种不同的显示思路:
- 点击外链,间接关上一个新的选项卡,在新的选项卡中展现新的页面。
- 点击外链,在以后我的项目中关上一个新的选项卡,选项卡中展现新的内容。
对于第一种状况我就不和大家演示了,对于第二种状况,我截个图给大家看下:
就是在以后我的项目的选项卡中,展现一个内部链接的内容。
咱们先来看第一种状况。即点击菜单之后,就在一个新的选项卡中关上网页,这种菜单的 JSON 格局如下:
{ "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" }}
这个大家看,也没有 children,因为不须要,这个显示的时候,就当成了只有一个 children 来解决,而后菜单项的 path 是一个 http 门路,一点击,天然就跳到新的选项卡了。
对于第二种状况,即点击外链,在以后我的项目中关上一个新的选项卡,选项卡中展现链接的内容,它的 JSON 构造相似上面这样:
{ "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" } } ]}
这个其实也没啥好说的,相似于下面系统监控的那种状况,然而只有一个子菜单,在菜单渲染的时候,也是只渲染一个子菜单。因为父子菜单的 path 都不是以 http 或者 https 之类的地址结尾,所以这个链接最终生成的 path 是 /www.javaboy.org
,而后这个门路的内容将展现在 InnerLink 组件上,最终就是大家上图中所看到的成果了。
好啦,这就是前端菜单的各种状况,后端菜单如何依照须要返回数据,咱们持续~
2. 菜单表
首先咱们来看看菜单表的定义,也就是 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. 前端菜单展现
接下来,前端菜单展现分为了几种状况?这个松哥在之前的文章中曾经和大家聊过了,具体能够参考Vue 里,多级菜单要如何设计才显得业余?一文,这里不再赘述。
4. 菜单接口
当用户登录胜利之后,会主动申请 /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 菜单列表 */@Overridepublic 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
所做的事件了,在剖析 menuService.buildMenus
办法之前,我感觉大家有必要先来回顾一下Vue 里,多级菜单要如何设计才显得业余?一文,再来捋一捋菜单的四种状况,咱们先来回顾下四种菜单格局:
[{ "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": "http://www.javaboy.org", "hidden": false, "component": "Layout", "meta": { "title": "TienChin健身官网", "icon": "guide", "noCache": false, "link": "http://www.javaboy.org" }},{ "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" } } ]}]
这四种菜单 JSON,从上往下显示成果顺次是:
- 一级菜单中有二级菜单,一级菜单不可点击,二级菜单点击后在左边关上相应的页面。
- 只有一个一级菜单,点击之后,左边关上相应的页面。
- 一个外链(只有一级菜单),点击之后,在新的选项卡中关上新的页面。
- 一个外链(只有一级菜单),点击之后,在以后零碎中关上新的页面(第三方页面通过 iframe 标签呈现在以后零碎中)。
牢记这四种不同的菜单状况,再来看 buildMenus
办法,就会容易很多了(下文我说菜单 1、2、3、4 别离对应下面的四种状况):
/** * 构建前端路由所须要的菜单 * * @param menus 菜单列表 * @return 路由列表 */@Overridepublic 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;}
这个办法一个核心思想就是格局转换,其余的都没啥,不过看似简略的逻辑里边,其实也暗藏了很多实现细节。
这个办法细看的话,会有很多中央感觉比拟绕。然而,小伙伴们认真回顾一下Vue 里,多级菜单要如何设计才显得业余?一文,在该文章中,松哥将前端展现进去的菜单分为了四种状况,依据那四种显示的状况,再来看这里的数据组装逻辑,就很好懂了。
首先咱们来看 router 根本属性的设置:
- 首先是可见性 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(对应菜单 4 的 children 的状况)。
c. 如果以后组件是一级菜单并且是 M 型并且不是外链,那么就在原有的 path 上加上 / 前缀(对应菜单 1 的一级菜单的 path 状况)。
d. 如果以后组件是一级菜单,且是 C 型菜单,那么设置 path 为 /(对应菜单 2、4 中一级菜单的 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 这两个参数就没啥好说的。
接下来就是三个分支的状况了。
- 首先第一个 if,解决的就是惯例状况,一级菜单中有二级菜单的状况(对应菜单 1 的一级菜单状况)。
- 第二个分支解决一级 C 型菜单是非外链的状况(对应菜单 2 的状况),此时主动给该菜单项加上一个 children。
- 第三个分支是解决一级 M 型菜单是外链的状况(对应菜单 4 的状况),此时主动给该菜单加上一个 children。
- 如果三个分支都不进去,实际上就是菜单 3 的状况了。
好啦,这就是菜单接口分析的全部内容了,有点绕,前面松哥再整几集视频和大家详细分析,对视频感兴趣的小伙伴戳这里:TienChin 我的项目配套视频来啦。