React的路由，怎么开发得劲儿

首先肯定业务场景

若是咱们把场景设定在开发一个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的路由开发起来得劲儿了很多，总体的解决方案已经肯定，供参考。

项目地址