TienChin 项目动态菜单接口分析
本文一定要结合Vue 里，多级菜单要如何设计才显得专业？一文一起食用效果良好，否则可能会看不懂。
做过 vhr 的小伙伴应该都知道动态菜单是咋回事，就是不同权限的用户登录成功之后，可以看到不同的菜单项，这在前后端不分的项目中，其实是很好实现的，然而在前后端分离项目中，实现起来略微有一些麻烦，不过不管怎么说，想要实现，总是有办法的，并且办法还不止一个！今天松哥就来和大家聊一聊 TienChin 项目中动态菜单的实现方案，一起来学习一个不同于 vhr 的动态菜单实现思路。
TienChin 项目基于 RuoYi-Vue 脚手架，所以接下来的分析也是在说 RuoYi-Vue 这个脚手架中动态菜单的实现方案。
1. 菜单表
首先我们来看看菜单表的定义，也就是 sys_menu。
1 | CREATE TABLE `sys_menu` ( |
其实这里很多字段都和我们 vhr 项目项目很相似，我也就不重复啰嗦了，我这里主要和小伙伴们说一个字段，那就是 menu_type。
menu_type 表示一个菜单字段的类型，一个菜单有三种类型，分别是目录（M）、菜单（C）以及按钮（F）。这里所说的目录，相当于我们在 vhr 中所说的一级菜单，菜单相当于我们在 vhr 中所说的二级菜单。
当用户从前端登录成功后，要去动态加载的菜单的时候，就查询 M 和 C 类型的数据即可，F 类型的数据不是菜单项，查询的时候直接过滤掉即可，通过 menu_type 这个字段可以轻松的过滤掉 F 类型的数据。小伙伴们想想，F 类型的数据过滤掉之后，剩下的数据不就是一级菜单和二级菜单了，那不就和 vhr 又一样了么！
在 vhr 中，考虑到菜单就是只有两级：一级菜单和二级菜单，一级菜单是目录，二级菜单是则是具体的菜单项，没有三级菜单！所以在 vhr 中，查询菜单的时候我直接用了一个一对多的查询，将一级菜单做一的一方，二级菜单做多的一方，这样比较省事。当然灵活度差一点，所以在 TienChin 项目中，这块还是用上了递归。
2. 前端菜单展示
接下来，前端菜单展示分为了几种情况？这个松哥在之前的文章中已经和大家聊过了，具体可以参考Vue 里，多级菜单要如何设计才显得专业？一文，这里不再赘述。
3. 菜单接口
当用户登录成功之后，会自动请求 /getRouters 接口来获取菜单信息，我们一起来看下：
1 | /** |
这里的查询实际上分为两个步骤：
- 根据用户 id 查询到所有的菜单信息，这一步的查询实际上是比较容易的，就单纯的多张表联合在一起，然后过滤出和当前用户相关并且菜单类型为 M 或者 C 的菜单（类型为 F 的表示按钮，就不要了），查询到菜单信息之后，然后进行一个递归操作，将菜单数据的层级排列出来。
menuService.buildMenus这一步则是将菜单数据专为前端所需要的路由数据。
一共就这两个步骤，我们来逐一进行分析。
先来看查询菜单数据。
1 | /** |
这里一共涉及到五个关键方法，我们来逐一进行分析：
- selectMenuTreeByUserId：这个方法的执行比较容易，如果当前用户是管理员，那就不用加过滤条件了，直接查询出所有的类型为 M 和 C 的菜单项即可。
- getChildPerms：这个方法主要是将前面查询出来的菜单数据进行重组，本来都是一个集合中的数据，现在在该方法中处理成树状，处理的核心逻辑就是调用 recursionFn 方法将之进行递归。
- recursionFn：这是最为关键的递归方法了，首先调用 getChildList 获取当前菜单项的 children，然后将获取到的 children 设置给当前菜单项，最后还要遍历获取到的 children，如果这个 children 也是有子菜单的，则继续调用 recursionFn 方法进行处理。
- getChildList：这个是查询某一个菜单的子菜单，这个很容易，如果某一个菜单的 parentId 是当前菜单的 id，那么这个菜单就是当前菜单的子菜单。
- hasChild：这个是判断给定的菜单是否有子菜单，这个逻辑就比较简单了。
好啦，这个就是整个的查询逻辑，整体上来说是比较容易的，就是查询 M 和 C 类型的菜单，然后再做一个递归操作，将菜单数据变成一个树状数据。
但是因为 SysMenu 和前后端所需要的路由数据的字段名称对不上，并且格式参数等都不符合前端的要求，所以还需要再做一个转换，这就是 menuService.buildMenus 所做的事情了，在分析 menuService.buildMenus 方法之前，我觉得大家有必要先来回顾一下Vue 里，多级菜单要如何设计才显得专业？一文，再来捋一捋菜单的四种情况，我们先来回顾下四种菜单格式：
1 | [{ |
这四种菜单 JSON，从上往下显示效果依次是：
- 一级菜单中有二级菜单，一级菜单不可点击，二级菜单点击后在右边打开相应的页面。
- 只有一个一级菜单，点击之后，右边打开相应的页面。
- 一个外链（只有一级菜单），点击之后，在新的选项卡中打开新的页面。
- 一个外链（只有一级菜单），点击之后，在当前系统中打开新的页面（第三方页面通过 iframe 标签出现在当前系统中）。
牢记这四种不同的菜单情况，再来看 buildMenus 方法，就会容易很多了（下文我说菜单 1、2、3、4 分别对应上面的四种情况）：
1 | /** |
这个方法一个核心思想就是格式转换，其他的都没啥，不过看似简单的逻辑里边，其实也隐藏了很多实现细节。
这个方法细看的话，会有很多地方感觉比较绕。但是，小伙伴们仔细回顾一下Vue 里，多级菜单要如何设计才显得专业？一文，在该文章中，松哥将前端展示出来的菜单分为了四种情况，根据那四种显示的情况，再来看这里的数据组装逻辑，就很好懂了。
首先我们来看 router 基本属性的设置：
- 首先是可见性 hidden，这个没啥好说的。
- 接下来是菜单的 name 属性，name 属性分为了两种情况：路由的 name 属性是菜单表中的 path 字段值且首字母大写（菜单 1、3、4）；如果在一级菜单中，出现了一个菜单 C（本来这一级别只有 M），并且还不是外链，那么就设置菜单的 name 为空字符串（相当于此时不需要 name 属性了，对应菜单 2 的情况）。
- 接下来是路由的 path，设置 path 的时候也分好种情况，松哥对照着代码来和大家说一下：
1 | /** |
a. 首先获取从数据库中查询到的 path 属性。
b. 如果当前组件不是一级菜单，并且是在内部组件中展示，那么除去这个 path 里边的 http 或者 https（对应菜单 4 的 children 的情况）。
c. 如果当前组件是一级菜单并且是 M 型并且不是外链，那么就在原有的 path 上加上 / 前缀（对应菜单 1 的一级菜单的 path 情况）。
d. 如果当前组件是一级菜单，且是 C 型菜单，那么设置 path 为 /（对应菜单 2、4 中一级菜单的 path 情况）。
e. 其他情况，菜单都是从数据库查到什么返回什么。
- 接下来是设置前端 component，这个菜单项用哪个 component 组件显示出来。
1 | /** |
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 项目配套视频来啦。
