首先确定业务场景
如果我们把场景设定在开发一个pc端管理后台的话，那么很常见的需求就是根据不同用户，配置不同的权限，显示不同的菜单项目，渲染不同的路由。
那权限到底归谁管
一般来说都是后台配置权限，然后驱动前端显示菜单，但我觉得这样不太好，加一个menu就要向后台申请，太不灵活，费劲儿。
我觉得应该也给前台一定程度的权利，让其可以“绕过”后台主导一部分菜单项和路由项的渲染.
一言以蔽之：
前后台协同把事情办了，后台为主，前端为辅。
基于以上分析，制定了一个解决方案
首先列出一下“出场角色”：
动态结构数据 ：通过前后台协同创建数据，其描述的是一种树状关系。
静态内容数据 ：渲染路由和菜单项的基本数据信息。
菜单项和其关联的路由 ：根据以上数据驱动显示。
静态内容配置
主要为两个成员:
路由配置：routesMap
-
菜单项配置：menusMap
二者相关性太高，故在一起进行管理。
路由配置：routesMap
作用：
每一个路由都是一个单体对象，通过注册routesMap内部来进行统一管理。
结构：
{
...
{
name: "commonTitle_nest", //国际化单位ID
icon: "thunderbolt", //antd的icon
path: "/pageCenter/nestRoute", //路径规则
exact: true, //是否严格匹配
component: lazyImport(() =>
import('ROUTES/login')
), //组件
key: uuid() //唯一标识
}
...
}
个体参数一览：
| 参数 | 类型 | 说明 | 默认值 | |
|---|---|---|---|---|
| name | string | 国际化的标识ID | _ | |
| icon | string | antd的icon标识 | - | |
| path | string | 路径规则 | - | |
| exact | boolan | 是否严格匹配 | false | |
| component | string | 渲染组件 | - | |
| key | string | 唯一标识 | - | |
| redirect | string | 重定向路由地址 | - | |
| search | object | "?=" | - | |
| param | string | number | "/*" | - |
| isNoFormat | boolean | 标识拒绝国际化 | false |
基本是在react-router基础上进行扩展的，保留了其配置项。
菜单项配置：menusMap
作用：
每个显示在左侧的菜单项目都是一个单体对象，菜单单体内容与路由对象进行关联，并通过注册routesToMenuMap内部来进行统一管理。
结构：
{
...
[LIGHT_ID]: {
...routesMap.lightHome,
routes: [
routesMap.lightAdd,
routesMap.lightEdit,
routesMap.lightDetail,
],
}
...
}
个体参数一览：
| 参数 | 类型 | 说明 | 默认值 |
|---|---|---|---|
| routes | array | 转载路由个体 | _ |
该个体主要关联路由个体，故其参数基本与之一致
动态结构配置
主要为两个类别：
menuLocalConfig.json：前端期望的驱动数据。
menuRemoteConfig.json：后端期望的驱动数据。
作用：
动静结合，驱动显示：两文件融合作为动态数据，去激活静态数据（菜单项menusMap）来驱动显示菜单项目和渲染路由组件。
强调：
menuLocalConfig.json：是动态数据的组成部份，是“动”中的“静”，完全由前端主导配置。
menuRemoteConfig.json：应该由后台配置权限并提供，前端配置该数据文件，目的是在后台未返回数据作默认配置，还有模拟mock开发使用。
结构：
[
...
{
"menuId": 2001,
"parentId": 1001
}
...
]
简单，直接地去表示结构的数据集合
动态配置的解释：
简单讲，对于驱动菜单项和路由的渲染，无论后台配置权限控制前端也好，前端想绕过后端主导显示也好，都是一种期望（种因）。二者协商，结合，用尽可能少的信息描述一个结构（枝繁），从而让静态数据对其进行补充（叶茂），然后再用形成的整体去驱动（结果）。
快速上手
注册路由个体
位置在/src/routes/config.js,栗：
/* 路由的注册数据，新建路由在这配置 */
export const routesMap = {
...
templates: {
name: "commonTitle_nest",
icon: "thunderbolt",
path: "/pageCenter/nestRoute",
exact: true,
redirect: "/pageCenter/light",
key: uuid()
}
...
}
详：/路由相关/配置/静态内容配置
决定该路由个体的“出场”
位置同上,栗：
/* 路由匹配menu的注册数据，新建后台驱动的menu在这配置 */
export const menusMap = {
...
[LIGHT_ID]: {
...routesMap.lightHome, //“主角”
routes: [
routesMap.lightAdd, //“配角”
routesMap.lightEdit,
routesMap.lightDetail,
],
},
...
}
解：首先路由个体出现在该配置中，就说明出场（驱动渲染route）了，但是出场又分为两种：
| 类别 | 驱动显示了左侧 MenuItem | 可以跳转么 |
|---|---|---|
| 主角 | 有 | 可以 |
| 配角 | 没有 | 可以 |
以上就已经完成了静态数据的准备，接下来就等动态结构数据类激活它了。
配置动态结构数据
后台配置的权限：
[
{ "menuId": 1002, "parentId": 0 },
{ "menuId": 1001, "parentId": 0 }
]
主导
前端自定义的权限:
[
{ "menuId": 2002, "parentId": 1001 },
{ "menuId": 2001, "parentId": 1001 },
{ "menuId": 2003, "parentId": 0 },
{ "menuId": 2004, "parentId": 1002 },
{ "menuId": 2005, "parentId": 1002 }
]
补充
解：1***和2***分别是后台和前台的命名约定(能区分就行，怎么定随意)，通过以上数据不难看出二者结合描述了一个树状关系，进而去激活静态数据以驱动渲染页面的菜单和路由。
简单讲：就是动态数据描述结构，静态数据描述内容，结构去和内容进行匹配，有就显示，没有也不会出问题，二者配合驱动显示。
至此配置基本完成，可以通过直接修改该文件的方式进行开发和调整，也可以可视化操作。
配置调整费劲？拖拽吧
操作后自动刷新。
<p align="center">
<img style="
width: 80%;
" src="https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/99a4283e26e848c08f1f217d51c96956~tplv-k3u1fbpfcp-zoom-1.image">
</p>
自动生成文件
menuLocalConfig.json
menuRemoteConfig.json
总结：
这样我觉得react的路由开发起来得劲儿了不少，整体的解决方案已经确定，供参考。
