老生常谈了！
虽然我们是 Java 猿，但是写起来前端代码也不含糊！今天我想来和大家聊聊这个前端的动态菜单，要如何设计才显得专业！还是以我们的 TienChin 项目为例，大家一起来看看。
先来一张截图看看效果：
那么这样的菜单是如何设计出来的呢？
今天我也不想和大家聊过多的技术细节，就聊聊这个路由是如何设计的，一旦大家明白了路由是如何设计的，剩下的问题都是细枝末节的问题了。
有的小伙伴做过 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：
这里我举了两个菜单的例子，这两个例子比较具有代表性，这个菜单最终显示效果大概类似下面这样：
- 系统监控
- 在线用户
- 定时任务
- 角色管理
大概显示效果如上图。
接下来我就来说一下这里几个典型属性：
- redirect：noRedirect 表示该路由在面包屑导航中不可被点击。
- alwaysShow：如果这个属性设置为 false，那么当当前菜单只有一个子菜单的时候，默认情况下就只会显示子菜单，而忽略父菜单（如 1.1 小节所述），但是如果将该属性设置为 true，则无论当前菜单有几个子菜单，都会将当前菜单展示出来（这就类似于 vhr 中的效果了）。
- 每一个父菜单都有自己的 path，每一个 children 也有自己的 path，父菜单的 path 加上每一个 children 的 path，共同组成每一个 children 的路径。
- 再来看第二个角色管理这个菜单项，由于它的父菜单中只有一个子菜单项，并且父菜单中也没有 alwaysShow 属性，所以这个菜单项在最终展示的时候，就只展示里边的角色管理，父菜单则不会展示出来（正好，生成的 JSON 中也没说父菜单的名字、图标等属性）。
当然，不是说你的 JSON 这么写就自动这么显示，JSON 中的东西只是一个标记，最终怎么显示，还要看渲染：
还有一个函数我就没有列出来了，反正我们看名字也大概知道每一个函数的含义。
大家看，这个 div 中实际上分为了两部分，上面 template 专门用来处理 children 中只有一项的情况（角色管理），具体处理方式就是把 children 拿出来显示，其他的则不考虑，具体执行的时候不一定是只有一个 children，也有可能压根就没有 children，此时直接显示 parent 即可（参考 1.3 小节）。
下面的 el-submenu 则处理 children 有多个的情况（系统监控）。
另外这里涉及到了一个 resolvePath，也是特别关键的一个方法，我们来大致看下：
这个函数的主要左右，就是处理菜单的路径问题。
我们来看下这个具体的判断逻辑：
- 如果这个菜单的路径是一个外链（判断逻辑是查看这个 path 是否有 http 或者 https 等前缀），即 isExternal 返回 true，就把这个路径原封不动返回。
- 如果这个菜单的父菜单的路径是一个外链，则将父菜单的 path 原封不懂返回。
- 如果有查询参数，就把参数加上。
- 最后通过 path.resolve 对路径进行一个简单运算。
有的小伙伴可能对 path.resolve 不熟悉，我简单说下：
path.resolve() 方法可以将多个路径解析为一个规范化的绝对路径，它的处理方式类似于对这些路径逐一进行 cd 操作，然而与 cd 操作不同的是，这些路径可以是文件，并且可不必实际存在（resolve() 方法不会利用底层的文件系统判断路径是否存在，而只是进行路径字符串操作）。例如：
相当于：
举个简单的例子：
现在大家知道菜单跳转的路径是怎么来的了吧！
1.3 外链问题
在 TienChin 项目中，菜单还存在一个外链的问题。
这个外链有两种不同的显示思路：
- 点击外链，直接打开一个新的选项卡，在新的选项卡中展示新的页面。
- 点击外链，在当前项目中打开一个新的选项卡，选项卡中展示新的内容。
对于第一种情况我就不和大家演示了，对于第二种情况，我截个图给大家看下：
就是在当前项目的选项卡中，展示一个外部链接的内容。
我们先来看第一种情况。即点击菜单之后，就在一个新的选项卡中打开网页，这种菜单的 JSON 格式如下：
这个大家看，也没有 children，因为不需要，这个显示的时候，就当成了只有一个 children 来处理，然后菜单项的 path 是一个 http 路径，一点击，自然就跳到新的选项卡了。
对于第二种情况，即点击外链，在当前项目中打开一个新的选项卡，选项卡中展示链接的内容，它的 JSON 结构类似下面这样：
这个其实也没啥好说的，类似于上面系统监控的那种情况，但是只有一个子菜单，在菜单渲染的时候，也是只渲染一个子菜单。由于父子菜单的 path 都不是以 http 或者 https 之类的地址开头，所以这个链接最终生成的 path 是 ，然后这个路径的内容将展示在 Innerlink 组件上，最终就是大家上图中所看到的效果了。
好啦，这就是前端菜单的各种情况，后端菜单如何按照需要返回数据，咱们继续～
首先我们来看看菜单表的定义，也就是 。
其实这里很多字段都和我们 vhr 项目项目很相似，我也就不重复啰嗦了，我这里主要和小伙伴们说一个字段，那就是 。
表示一个菜单字段的类型，一个菜单有三种类型，分别是目录（M）、菜单（C）以及按钮（F）。这里所说的目录，相当于我们在 vhr 中所说的一级菜单，菜单相当于我们在 vhr 中所说的二级菜单。
当用户从前端登录成功后，要去动态加载的菜单的时候，就查询 M 和 C 类型的数据即可，F 类型的数据不是菜单项，查询的时候直接过滤掉即可，通过 这个字段可以轻松的过滤掉 F 类型的数据。小伙伴们想想，F 类型的数据过滤掉之后，剩下的数据不就是一级菜单和二级菜单了，那不就和 vhr 又一样了么！
在 vhr 中，考虑到菜单就是只有两级：一级菜单和二级菜单，一级菜单是目录，二级菜单是则是具体的菜单项，没有三级菜单！所以在 vhr 中，查询菜单的时候我直接用了一个一对多的查询，将一级菜单做一的一方，二级菜单做多的一方，这样比较省事。当然灵活度差一点，所以在 TienChin 项目中，这块还是用上了递归。
接下来，前端菜单展示分为了几种情况？这个松哥在之前的文章中已经和大家聊过了，具体可以参考Vue 里，多级菜单要如何设计才显得专业？一文，这里不再赘述。
当用户登录成功之后，会自动请求 接口来获取菜单信息，我们一起来看下：
这里的查询实际上分为两个步骤：
- 根据用户 id 查询到所有的菜单信息，这一步的查询实际上是比较容易的，就单纯的多张表联合在一起，然后过滤出和当前用户相关并且菜单类型为 M 或者 C 的菜单（类型为 F 的表示按钮，就不要了），查询到菜单信息之后，然后进行一个递归操作，将菜单数据的层级排列出来。
- 这一步则是将菜单数据专为前端所需要的路由数据。
一共就这两个步骤，我们来逐一进行分析。
先来看查询菜单数据。
这里一共涉及到五个关键方法，我们来逐一进行分析：
- selectMenuTreeByUserId：这个方法的执行比较容易，如果当前用户是管理员，那就不用加过滤条件了，直接查询出所有的类型为 M 和 C 的菜单项即可。
- getChildPerms：这个方法主要是将前面查询出来的菜单数据进行重组，本来都是一个集合中的数据，现在在该方法中处理成树状，处理的核心逻辑就是调用 recursionFn 方法将之进行递归。
- recursionFn：这是最为关键的递归方法了，首先调用 getChildList 获取当前菜单项的 children，然后将获取到的 children 设置给当前菜单项，最后还要遍历获取到的 children，如果这个 children 也是有子菜单的，则继续调用 recursionFn 方法进行处理。
- getChildList：这个是查询某一个菜单的子菜单，这个很容易，如果某一个菜单的 parentId 是当前菜单的 id，那么这个菜单就是当前菜单的子菜单。
- hasChild：这个是判断给定的菜单是否有子菜单，这个逻辑就比较简单了。
好啦，这个就是整个的查询逻辑，整体上来说是比较容易的，就是查询 M 和 C 类型的菜单，然后再做一个递归操作，将菜单数据变成一个树状数据。
但是因为 SysMenu 和前后端所需要的路由数据的字段名称对不上，并且格式参数等都不符合前端的要求，所以还需要再做一个转换，这就是 所做的事情了，在分析 方法之前，我觉得大家有必要先来回顾一下Vue 里，多级菜单要如何设计才显得专业？一文，再来捋一捋菜单的四种情况，我们先来回顾下四种菜单格式：
这四种菜单 JSON，从上往下显示效果依次是：
- 一级菜单中有二级菜单，一级菜单不可点击，二级菜单点击后在右边打开相应的页面。
- 只有一个一级菜单，点击之后，右边打开相应的页面。
- 一个外链（只有一级菜单），点击之后，在新的选项卡中打开新的页面。
- 一个外链（只有一级菜单），点击之后，在当前系统中打开新的页面（第三方页面通过 iframe 标签出现在当前系统中）。
牢记这四种不同的菜单情况，再来看 方法，就会容易很多了（下文我说菜单 1、2、3、4 分别对应上面的四种情况）：
这个方法一个核心思想就是格式转换，其他的都没啥，不过看似简单的逻辑里边，其实也隐藏了很多实现细节。
这个方法细看的话，会有很多地方感觉比较绕。但是，小伙伴们仔细回顾一下Vue 里，多级菜单要如何设计才显得专业？一文，在该文章中，松哥将前端展示出来的菜单分为了四种情况，根据那四种显示的情况，再来看这里的数据组装逻辑，就很好懂了。
首先我们来看 router 基本属性的设置：
- 首先是可见性 hidden，这个没啥好说的。
- 接下来是菜单的 name 属性，name 属性分为了两种情况：路由的 name 属性是菜单表中的 path 字段值且首字母大写（菜单 1、3、4）；如果在一级菜单中，出现了一个菜单 C（本来这一级别只有 M），并且还不是外链，那么就设置菜单的 name 为空字符串（相当于此时不需要 name 属性了，对应菜单 2 的情况）。
- 接下来是路由的 path，设置 path 的时候也分好种情况，松哥对照着代码来和大家说一下：
a. 首先获取从数据库中查询到的 path 属性。
b. 如果当前组件不是一级菜单，并且是在内部组件中展示，那么除去这个 path 里边的 http 或者 https（对应菜单 4 的 children 的情况）。
c. 如果当前组件是一级菜单并且是 M 型并且不是外链，那么就在原有的 path 上加上 / 前缀（对应菜单 1 的一级菜单的 path 情况）。
d. 如果当前组件是一级菜单，且是 C 型菜单，那么设置 path 为 /（对应菜单 2、4 中一级菜单的 path 情况）。
e. 其他情况，菜单都是从数据库查到什么返回什么。
- 接下来是设置前端 component，这个菜单项用哪个 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 的情况了。