React中的权限组件设计问题怎么解决

这篇“React中的权限组件设计问题怎么解决”文章的知识点大部分人都不太理解，所以小编给大家总结了以下内容，内容详细，步骤清晰，具有一定的借鉴价值，希望大家阅读完这篇文章能有所收获，下面我们一起来看看这篇“React中的权限组件设计问题怎么解决”文章吧。权限管理是中后台系统中常见的需求之一。之前做过基于 Vue 的后台管理系统权限控制，基本思路就是在一些路由钩子里做权限免费云主机域名比对和拦截处理。最近维护的一个后台系统需要加入权限管理控制，这次技术栈是React，我刚开始是在网上搜索一些React路由权限控制，但是没找到比较好的方案或思路。这时想到ant design pro内部实现过权限管理，因此就专门花时间翻阅了一波源码，并在此基础上逐渐完成了这次的权限管理。整个过程也是遇到了很多问题，本文主要来做一下此次改造工作的总结。原代码基于 react 16.x、dva 2.4.1 实现，所以本文是参考了ant-design-pro v1内部对权限管理的实现一般后台管理系统的权限涉及到两种：资源权限数据权限资源权限一般指菜单、页面、按钮等的可见权限。数据权限一般指对于不同用户，同一页面上看到的数据不同。本文主要是来探讨一下资源权限，也就是前端权限控制。这又分为了两部分：侧边栏菜单路由权限在很多人的理解中，前端权限控制就是左侧菜单的可见与否，其实这是不对的。举一个例子，假设用户guest没有路由/setting的访问权限，但是他知道/setting的完整路径，直接通过输入路径的方式访问，此时仍然是可以访问的。这显然是不合理的。这部分其实就属于路由层面的权限控制。关于前端权限控制一般有两种方案：前端固定路由表和权限配置，由后端提供用户权限标识后端提供权限和路由信息结构接口，动态生成权限和菜单我们这里采用的是第一种方案，服务只下发当前用户拥有的角色就可以了，路由表和权限的处理统一在前端处理。整体实现思路也比较简单：现有权限（currentAuthority）和准入权限（authority）做比较，如果匹配则渲染和准入权限匹配的组件，否则渲染无权限组件（403 页面）既然是路由相关的权限控制，我们免不了先看一下当前的路由表：这份路由表其实是我从控制台 copy 过来的，内部做了很多的转换处理，但最终生成的就是上面这个对象。这里每一级菜单都加了一个authority字段来标识允许访问的角色。component代表路由对应的组件：有了路由表这份基础数据，下面就让我们来看下如何通过一步步的改造给原有系统注入权限。先从src/router.js这个入口开始着手：这是一个非常常规的路由配置，既然要加入权限，比较合适的方式就是包一个高阶组件AuthorizedRoute。然后router.js就可以更替为：来看下AuthorizedRoute的大致实现：我们看一下这个组件有什么问题：页面可能允许多个角色访问，用户拥有的角色也可能是多个（可能是字符串，也可呢是数组）。直接在组件中判断显然不太合适，我们把这部分逻辑抽离出来：首先如果路由表中没有authority字段默认都可以访问。接着分别对authority为字符串和数组的情况做了处理，其实就是简单的查找匹配，匹配到了就可以访问，匹配不到就返回Exception，也就是我们自定义的异常页面。有一个点一直没有提：用户当前角色权限 currentAuthority 如何获取？这个是在页面初始化时从接口读取，然后存到 store 中有了这块逻辑，我们对刚刚的AuthorizedRoute做一下改造。首先抽象一个Authorized组件，对权限校验逻辑做一下封装：接着AuthorizedRoute可直接使用Authorized组件：这里采用了render props的方式：如果提供了component props就用component渲染，否则使用render渲染。菜单权限的处理相对就简单很多了，统一集成到SiderMenu组件处理：这里我只贴了一些核心代码，其中的checkPermissionItem就是实现菜单权限的关键。他同样用到了上文中的check方法来对当前菜单进行权限比对，如果没有权限就直接不展示当前菜单。以上就是关于“React中的权限组件设计问题怎么解决”这篇文章的内容，相信大家都有了一定的了解，希望小编分享的内容对大家有帮助，若想了解更多相关的知识内容，请关注百云主机行业资讯频道。

相关推荐: C#中wpf怎么利用附加属性实现界面上定义装饰器

这篇文章主要介绍了C#中wpf怎么利用附加属性实现界面上定义装饰器的相关知识，内容详细易懂，操作简单快捷，具有一定借鉴价值，相信大家阅读完这篇C#中wpf怎么利用附加属性实现界面上定义装饰器文章都会有所收获，下面我们一起来看看吧。装饰器是wpf中可以浮在控件上…