microRole

一种根据角色权限控制样式的方案

feature

• 基于配置，更改简单
• 无侵入，不影响原功能
• 无需刻意管理
• 配置更改时不需改动代码，更不需要打包
• 更灵活，多样的样式效果
• 适配微前端

#

对一个后台管理系统，完全可以把权限配置写死在前端，但大部分系统都不会采取这种不太聪明的方法而是将配置放在数据库，传回前端时转为动态路由和其他组件配置，来显示对应的路由/组件。实际上这样最大的好处是，当出现权限配置的更改时，比如普通用户在一周年活动的时候可以试用会员的权限等等 ，如果写死在前端的话，必须要回到代码去更改打包并重走一遍ci/cd。 也就是说，最终的目的是，当不是更改系统的功能的时候，不应该回到代码去进行更改，但即使做到了上述行为，在代码中更改依然是一个常见的事情，比如万圣节页面的样式要改变，或者客户单纯希望把某个按钮颜色变成蓝色，开发者又要跑到代码中去找对应的样式了

是的，我们可以把第一个案例中的行为复用到第二个，也就是把所有的相关样式放到数据库，然后再写一个管理系统的管理系统去管理管理系统的样式。 乍一看好像没有问题，但实际并非如此，在第一个案例中动态路由/组件配置 是跟系统的功能绑定的，也就是存在一个功能，对应一个路由/组件，而且只有两个选择：打开/关闭功能。更改权限的人，无论是管理者还是后端，只需要知道处理什么功能即可，无需关心路由/组件叫啥是啥

（前端提供一个路由/组件 到功能的映射）。

而在第二个情况中未必如此，管理人员大概率猜不出来“name:"userNameBtn"”对应的按钮是哪一个，他可能只想把用户界面下右上角的按钮转成紫色，他也没有办法找到对应的组件，也不知道该怎么改成紫色。当然也可以维护一个映射，但这可麻烦的多，大概率会是这样

let config={
    name:"userNameBtn",desc:"在用户界面，网址（/user），用户菜单一栏中点击用户名称，此时两个按钮中左边的那个"
}

即使真这么写了，前端开发人员觉得自己表示的很清楚了，但别人眼中可能是这样子

let 看不懂={
   name: "这啥意思"
   desc："已知小明身高一米五，地球直径大于一米五，你猜猜按钮在哪儿"
}

此外，也不可能把每一个dom样式都放到数据库里，不可能指望管理人员去手写行内样式之类的东西。而这样一个需求，又有那么一点点鸡肋，食之麻烦，弃之小可惜

难点

• 管理问题，可能在开发最初并不确定某组件是否权限相关，可能只是单纯地随着权限变颜色而无实际功能，可能在开发过程中需求更改，某组件可能得到权限功能or失去权限功能。可能写好了权限绑定组件的逻辑又要辛苦去删掉
• 改造问题，不可能为这样一个小需求去对项目架构进行改造吧
• 样式问题，因为生产地项目中多余的css会被摇掉，那么样式更改只能依靠外部提供styleor样式表
• 命名问题，管理人员定位组件依赖的是视觉，而非数据结构，前端要提供方便其他人员理解的方案
• 维护问题，现在是不用更改代码，但却要维护各种各样的映射了，实际上制作这些映射非常的乏味且复杂