注册

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() //唯一标识
}
...
}


个体参数一览:
参数类型说明默认值
namestring国际化的标识ID_
iconstringantd的icon标识-
pathstring路径规则-
exactboolan是否严格匹配false
componentstring渲染组件-
keystring唯一标识-
redirectstring重定向路由地址-
searchobject"?="-
paramstringnumber"/*"-
isNoFormatboolean标识拒绝国际化false

基本是在react-router基础上进行扩展的,保留了其配置项。

菜单项配置:menusMap

作用:

每个显示在左侧的菜单项目都是一个单体对象,菜单单体内容与路由对象进行关联,并通过注册routesToMenuMap内部来进行统一管理。

结构:
{
...
[LIGHT_ID]: {
...routesMap.lightHome,
routes: [
routesMap.lightAdd,
routesMap.lightEdit,
routesMap.lightDetail,
],
}
...
}


个体参数一览:
参数类型说明默认值
routesarray转载路由个体_

该个体主要关联路由个体,故其参数基本与之一致

动态结构配置

主要为两个类别:
  • __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***分别是后台和前台的命名约定(能区分就行,怎么定随意),通过以上数据不难看出二者结合描述了一个树状关系,进而去激活静态数据以驱动渲染页面的菜单和路由。

简单讲:就是动态数据描述结构,静态数据描述内容,结构去和内容进行匹配,有就显示,没有也不会出问题,二者配合驱动显示。

至此配置基本完成,可以通过直接修改该文件的方式进行开发和调整,也可以可视化操作。

配置调整费劲?拖拽吧

操作后自动刷新。

1460000040201707

自动生成文件
menuLocalConfig.json

menuRemoteConfig.json

总结:

这样我觉得react的路由开发起来得劲儿了不少,整体的解决方案已经确定,供参考。

0 个评论

要回复文章请先登录注册