首先确定业务场景
如果咱们把场景设定在开发一个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.jsonmenuRemoteConfig.json总结：
这样我感觉react的路由开发起来得劲儿了不少，整体的解决方案曾经确定，供参考。
我的项目地址