路由必须要提前定义在config文件中或者是约定形式吗？ 能不能从服务器上取？

[fanhualei]

路由+菜单+权限 是整个系统的核心。

突然有个奇怪的想法，

路由必须要提前定义在config文件中或者是约定形式吗？ 能不能从服务器上取？
或者只定义一部分路由，另外一部分从服务器上取，然后实现动态路由？

这个想法对吗？

为什么有这个想法，实际上想路由的过程中，又想到了权限，想如果不想让某些人访问某些路由怎么办？ 这实际上是一个权限问问，就没必要让路由解决了。

这个可以通过UMI的access来控制，另外这里的umi可能有安全漏洞(因为umi在前端，总觉得不保险)，所以后端的api接口，要做好第二层安全防护。

最后汇总一下：
把路由与权限搅和在一起了，实际上路由就是一个定义，例如你做静态页面，把不同文件放到不同文件夹中，到底能不能访问这些文件，那么要单独加一个权限控制。

应该选择定义路由还是约定路由？

约定路由就是不用维护config文件了。
约定路由有以下不爽的：
1、指定个性化layout时，要在某个文件夹中约定一个_layout，
2、不能指定name,也就是要搭配menuRender来实现菜单的显示。

定义路由的好处：
1、可以随意定义了
2、坏处定义麻烦

我也没有用过约定路由，所以这种对比不客观，这个没有结论。

选择了权限过滤，那么还用menuDataRender过滤菜单吗？

有两种可能性：
一种是过access滤掉了，那么还要menuDataRender有啥用？
一种是access没有过滤，就要用menuDataRender在过滤掉。

跟踪了antDesignPro的代码，在没有menuDataRender时，access会自动过滤掉菜单。

这里就要思考一个问题，都用access过滤了，为啥还要menuDataRender？
如果menuDataRender定义好了，access还会过滤掉吗？ 当然会了，这也是跟踪代码得到的

猜测一下antDesign为啥要用menuDataRender，可能基于以下原因：
你在config定义的菜单顺序时：菜单A  菜单B 菜单C . 实际上你想把菜单顺序改变成：菜单B 菜单A 菜单C。或者你使用的时约定式菜单，只能通过menuDataRender来处理。

那还有其他的功能吗？

menuDataRender怎么使用呢？ 假设是用默认的Layout，在app中使用。

下面有个例子，用来将菜单反转。当然实际情况下，这里要从服务器上获取。最好只获取一次，如果用户ID不变的话。不然又效率问题。

export const layout = ({
  initialState,
}: {
  initialState: { settings?: LayoutSettings };
}): BasicLayoutProps => {
  return {
    rightContentRender: () => <RightContent />,
    footerRender: () => <Footer />,
    ...initialState?.settings,
    menuDataRender: (menuData: MenuDataItem[]) => {
      console.log(menuData);
      const aaa = menuData.reverse();
      console.log(aaa);
      return aaa;
    },
  };
};

使用menuDataRender与access，会不会每次URL改变都要刷新一次呢？ 会不会有效率问题。

access只会执行一次。这个会不会有bug，当切换用户的时候，会不会不会改变权限呢？

menuDataRender很烦，每次url变化都会执行，所以要做缓存处理。如果登录用户变化了，就做缓存。

上面那么多配置文件，有啥用途呢？

用途：

• 路由：config.ts文件
  • 配置path 、 access、对应的component
  • name、icon 用来做多语言或菜单
  • 其他的都是react routs的配置项了
• 路由：约定式
  • 如果配置access呢？
    • 官网有一个说明，没看懂，这样就与access无法关联，权限很难解决。
• 菜单：menuDataRender
  • 这里面没有配置权限的地方
• 权限：access.ts
  • 只返回一个map，是否包含某个权限。
  • 例如：{ admin:true, superadmin:false }

这几种配置文件，功能有重复的地方，到底怎么组合用呢？

汇总一下使用场景，结论是，config与access`就能解决大部分应用场景了。 约定路由有坑。

权限过滤	菜单顺序变化	约定路由	解决方案	应用概率
无	无	无	方案1: * config文件配置	5%
有	无	无	方案2： * config文件配置 * access	85%
有	有	无	方案3: * config文件配置 * access * menuDataRender	5%
有	有/无	有	方案4: * access * menuDataRender	5%
无	有/无	有	方案5: * menuDataRender	5%

config.ts文件是提前写死的，那么权限怎么做成活的呢？

所以config.ts文件只能标记成最小分割单元，例如下面代码示例，每个path一个权限单元。然后在后台可以添加不同的角色，然后定义某个角色对应的canShop。 当让这里也可以将 access:‘/shop’

    // 新的一种布局
    {
      path: '/shop',
      layout: false,
      component: '@/layouts/nested',
      exact: false,
      icon: 'smile',
      access: 'canShop',     
      routes: [
        {
          name: 'overview',
          path: '/shop/overview',
          icon: 'HomeOutlined',
          access: 'canShopOverview', 
          routes: [
            {
              name: 'dashboard',
              path: '/shop/overview/dashboard',
              component: '@/pages/newLayout',
              access: 'canShopOverviewDashboard', 
            },
          ],
        },
    ............省略..................

这样做想名字，太麻烦了，另外一种操作是access与path名称相同。

export default function (props: any) {
  console.log(
    '===================================================================',
  );
  console.log(props);
  return {
    '/shop/overview/dashboard': true,
    '/shop/overview': false,
    '/admin/user': false,
  };
}

就像方程式一样，又回归到最原始了的阶段，只有path 对应最小单元的权限，才能在服务器后台做权限分配。

既然大部分情况下，config.ts中的path与access相同，为什么access默认不是path呢？ 这样就能简化很多。

回到原点，如果 UMI的路由，启动一部分是可以动态定义的，那么就没有这么多问题了，因为config.ts文件是写死的，所以这个写死的文件，只能作为最小的权限单元，这样在后台才能动态分组。 如果config.ts中的路由是动态的，就好操作多了。

结论： 路由必须要提前定义在config文件中或者是约定形式吗？ 能不能从服务器上取？
或者只定义一部分路由，另外一部分从服务器上取，然后实现动态路由？

[tanchang123]

我也想知道，手动艾特一下大佬解答一下，我记得他说好像现在不支持 @chenshuai2144

[JxSdGH]

插眼，等解决方案

[cdx111]

access用一个函数权限就是活的