
在许多企业服务网站或者后台系统需要制定各种权限来限制和隔离不同用户对资源的访问和操作

以下一些思路主要描述（我见过）的一些权限场景设计

## 设计概念

最常见的应用模式是 **[RBAC](https://en.wikipedia.org/wiki/Role-based_access_control) (Role-based access control)**
基于角色的访问控制机制。并且可以不增加复杂性的套用 **[MAC](https://en.wikipedia.org/wiki/Mandatory_access_control)** 和 **[DAC](https://en.wikipedia.org/wiki/Discretionary_access_control)** 的策略。

简单来说，RBAC 将 权限 <—> 用户 之间 加入 角色 这个概念进行关联和解耦，通过将含有不同权限的角色赋予用户，实现权限分配。

如果没有角色的话，用户的权限分配过程应该是这样：

~~PLACEHOLDER~~

单独进行每一种权限的配置，操作和管理成本比较高

而利用角色赋予用户权限，则减少了这样操作的成本，且能够大大减轻管理负担，同时将用户与权限解耦，提供更大的灵活性。

![image](https://user-images.githubusercontent.com/17287124/82122396-09aef080-97c6-11ea-8878-42046f62d104.png)

用户与角色的对应关系可以是 one to one，也可以是 one to many。

> 当关系是 one to many 时，用户的权限为角色组权限的并集
> 但这里并没有考虑互斥的情况

- 角色赋予的是主体，主体可以是用户，也可以是组
- 角色是权限的集合

RBAC 还具有以下细分的模型:

1. core RBAC
   - 最常见/简单的 RBAC 模型，我们这里主要讨论的是这一种
2. hierarchical RBAC, which adds support for inheritance between roles
   - 引入了角色继承(Hierarchical Role)概念，即角色之间具有分级的关系，
   - 比如管理职位权限分级，角色有 总监/组长/员工，上层角色继承下层角色的全部权限，而且可单独赋予更多独立
3. constrained RBAC, which adds separation of duties
   - 加入了角色的约束控制，包括但不限：互斥角色/基数约束/先决条件角色

我们日常也有很多用到 RBAC 模型的设计，比如 MacOS 的用户组

![image](https://user-images.githubusercontent.com/17287124/82122409-23503800-97c6-11ea-8533-d332e013dbe9.png)

## 具体实现

### 权限的规划拆分

为了实现拆分 **_权限_** 这个概念，我们首先要明确一般产品的权限 由 **页面访问/页面操作/页面数据** 构成

而 页面访问 与 页面操作 必定是关联的关系，也就是 页面操作的权限 前置依赖是角色具有 页面访问 的权限

而在大部分场景，我们可以把 页面操作 和 页面数据 作为统一的整体来设计

### 权限控制的具体实现

> 相信过程

### Step - 1

以 Integer 约定权限，比如我们有一组定义不同成员的权限：

```jsx
const ROLE_AUTH = {
    OWNER: 100,
    ADMIN: 90,
    ENGINEER: 80,
	DESIGNER: 75
    GUEST: 30,
};
```

我们定义 ROLE_AUTH 为权限表的集合，其中有不同权限的角色，权限的划分基于数字。

权限的数值越大表示权利越大且权利是向下覆盖的，也就是 owner 会拥有所有其以下角色的权限。

所以我们在代码中进行权限处理是这个样子：

```jsx
if (user.permission >= ROLE_AUTH.ENGINEER) {
  // do something
}
```

这种实现方式比较简单，但仔细看会有权限强覆盖的问题，比如各个角色之间是强关联的

ENGINEER 会拥有 DESIGNER 的全部权限

且未来增减改动角色权限都不容易

### Step - 2

利用 位运算

Linux 的文件权限 就是利用位运算实现的

在深入之前，我们先假定两个前提

1. 每种权限对应唯一的码
2. 权限码为二进制数形式，有且只有一位值为 1，其余全部为 0（`2^n`）

先来上操作方式的总结：

- `|`  赋予权限
- `&`  校验权限
- `& (~R)` 删除权限

Linux 的文件权限分为读、写和执行，有字母和数字等多种表现形式：

[Linux 的文件权限](https://www.notion.so/ac773ccb0e6647b48a340baa418718c0)

```jsx
let r = 0b100;
let w = 0b010;
let x = 0b001;

// 给用户赋全部权限（使用前面讲的 | 操作）
let user = r | w | x;

console.log(user);
// 7

console.log(user.toString(2));
// 111

//     r = 0b100
//     w = 0b010
//     r = 0b001
// r|w|x = 0b111
// 表明拥有了全部三个权限

// ------------------------------------

let r = 0b100;
let w = 0b010;
let x = 0b001;

// 给用户赋 r w 两个权限
let user = r | w;
// user = 6
// user = 0b110 (二进制)

console.log((user & r) === r); // true  有 r 权限
console.log((user & w) === w); // true  有 w 权限
console.log((user & x) === x); // false 没有 x 权限

// ------------------------------------

let r = 0b100;
let w = 0b010;
let x = 0b001;
let user = 0b110; // 有 r w 两个权限

// 删除 r 权限
user = user & ~r;

console.log((user & r) === r); // false 没有 r 权限
console.log((user & w) === w); // true  有 w 权限
console.log((user & x) === x); // false 没有 x 权限

console.log(user.toString(2)); // 现在 user 是 0b010

// 再执行一次
user = user & ~r;

console.log((user & r) === r); // false 没有 r 权限
console.log((user & w) === w); // true  有 w 权限
console.log((user & x) === x); // false 没有 x 权限

console.log(user.toString(2)); // 现在 user 还是 0b010，并不会新增
```

在用此种实现方式，可以注意到，用户/角色/权限 之间的对应关系减少了，进制转换的方法则可以省略对应关系表，减少查询，节省空间

适合应用极其多，但用户和角色比较少的场景

位运算的可读性不高，增加后期可维护性

### Step - 3

> 最后的方案

我们想实现一个角色之间是没有关联的权限系统，也就是说，角色的权限可以有交集也可以有差异，并且支持自定义配置。

实现的方式是设计一张权限表，那么如何设计呢？

~~PLACEHOLDER~~

上图很直观的描述了权限归原的方式

我们来介绍一下 如何定义 `Permission`

### Function

表示一个模块或者一个功能

```jsx
{
	function: 'WEBSITE', // 网站 模块
}
```

### Action

表示一个动作或者一个操作

```jsx
{
	action: 'View', // View / Create / Update / Delete
}
```

### Permission

所以最终的权限 由 `Function` 与 `Action` 组合而成

`Permission = Function + Action`

```jsx
// 代表拥有 网站访问 的权限
{
	function: 'WEBSITE',
	action: 'View',
}
```

注意不要使用 Anti-patterns

```jsx
// 访问网站应当是 Permission = 'WEBSITE' + 'View'
{
	function: 'VIEW_WEBSITE'
}
```

这样我们就可以定义许多有独立作用域的具体权限了

接下来我们就可以定义 `Role`

`Role` 表示一个 角色 或者 用户组

还可以多定义一个 `RolePermission` 表示一个 `Role` 具有哪些 `Permission`

我们可以为自定义 `RolePermission` 所包含的哪些`Permission`，并且将 `RolePermission` 集合 赋予 `Role` 。

所以只要去获取当前 `Role` 对应的 `RolePermission` 集合中具有哪些 `Permission` ，然后去匹配各个页面模块或功能具有的权限配置。

这样我们就实现了满足需求的简单权限系统。

## Reference

- [Role-based access control](https://en.wikipedia.org/wiki/Role-based_access_control)
- [为什么不要在 JavaScript 中使用位操作符？](https://jerryzou.com/posts/do-you-really-want-use-bit-operators-in-JavaScript)
- [权限系统设计](https://zhuanlan.zhihu.com/p/73414693)
- [角色权限设计的 100 种解法](https://mp.weixin.qq.com/s/MKljuxfDMmopr_MrnYljGw)


权限设计的一些思路


## Why

`React` 目前最新的公开版本为 `16.7`，而 目前项目版本为 `15.5`。

### 对比有如下重要变化：

### 新核心架构：Fiber （16.0）

异步渲染：周期性地对浏览器执行调度渲染工作的策略。
通过异步渲染，避免阻塞了主线程，实施更快地响应。

异步渲染能够将渲染任务划分为多块，这意味着几乎所有的行为都是同步发生的。
React 16.X 使用浏览器提供的 API 间歇性地检查当前是否还有其他任务需要完成，从而实现了对主线程和渲染过程的间接管理。
例如拖动、onChange 等在不考虑防抖情况，以及频繁 setState 的场景，相对于之前版本，有一定性能的提升。

这意味着 React 可以在更细的粒度上控制组件的绘制过程，从最终的用户体验来讲，用户可以体验到更流畅交互及动画体验。而因为异步渲染涉及到 React 的方方面面甚至未来，在 16.0 版本中 React 还暂时没有启用

> [GitHub - acdlite/react-fiber-architecture: A description of React’s new core algorithm, React Fiber](https://github.com/acdlite/react-fiber-architecture) > [New Core Algorithm · Issue #6170 · facebook/react · GitHub](https://github.com/facebook/react/issues/6170)

### 减少文件体积 （16.0）

React 16 对比 15.6.1

```plaintext
react 从20.7kb（gzip 后：6.9 kb）减至大小为 5.3 kb（gzip 后：2.2 kb）。
react-dom 从141 kb（gzip 后：42.9 kb）减至 103.7 kb（gzip 后：32.6 kb）。
react + react-dom 从 161.7 kb（gzip 后：49.8 kb）减至 109 kb（gzip 后：34.8 kb）
```

### 更好地 SSR （16.0）

[What’s New With Server-Side Rendering in React 16 – Hacker Noon](https://hackernoon.com/whats-new-with-server-side-rendering-in-react-16-9b0d78585d67)

### Fragment （16.2）

我们编写组件常见模式是将一个组件返回多个元素。
为了包裹多个元素肯定写过的 `div` 或 `span`，为了不必要的嵌套，提出了 `Fragment`

`Fragments` 与 `Vue.js` 的 `<template>` 功能类似，做不可见的包裹元素。

Fragments 简写形式 `<></>`

> 新版 React 还支持直接返回数组

### New LifeCycle （16.3）

官方团队在实现更好地 SSR 时发现有些现有的生命周期经常被开发者误用或者“巧妙”的使用，这些生命周期容易带来不好的实践。它们是：

1. `componentWillMount`
2. `componentWillReceiveProps`
3. `componentWillUpdate`

这三个生命周期将在 17.0 版本之前，启用 `Strict Mode` 下 console 警告 ⚠️

并在 17.0 之后，必须加前缀 `UNSAFE_` 才能正常使用。

未来版本将逐步去掉这三个生命周期。

#### React 16.3 一并带来了 两个新的生命周期：

1. `static getDerivedStateFromProps`
2. `getSnapshotBeforeUpdate`

```js
class Example extends React.Component {
  static getDerivedStateFromProps(props, state) {
    // ...
  }
}
```

- `static getDerivedStateFromProps` 返回要更新的 state 内容，返回 null 表示没有 state 需要更新（为差异化更新 state，与现有 setState 方式一致；与 React Hooks 方式不同）

```js
class Example extends React.Component {
  getSnapshotBeforeUpdate(prevProps, prevState) {
    // ...
  }
}
```

### New Context API （16.3）

现有 Context API 一直被官方定义为实验性 API，有许多问题：

1. 违反目前 React 组件设计。无法将使用 context 的子组件无缝移植到其他的根组件树种

2. 在 Context 值更新后，顶层组件向目标组件 的 props 透传过程中，如果中间过程的某个组件的 `shouldComponentUpdate` 返回了 false，所以无法触发之后子组件的 reRender，导致无法得到新的 Context 值

而 新的 Context API 解决了以上的问题，并且采用声明式写法。小型复杂组件间适合采用 Context

### React.memo （16.6）

类似于 Class 组件使用的 `PureComponent`

这是为 `functional component` 实现的过滤层，只有在 props 变化（浅比较）才会更新组件。

```js
const MyComponent = React.memo(function MyComponent(props) {
  // XXX
});
```

### Lazy （16.6）

Lazy

```js
const OtherComponent = React.lazy(() => import('./OtherComponent'));

function MyComponent() {
  return (
    <div>
      <OtherComponent />
    </div>
  );
}
```

`Suspense` 用来添加一个 placeholder，在 lazy 化 component 加载之前显示
fallback 是懒加载组件载入过程中的一个过渡，可以放一些过渡效果或方法。

> 目前不能 SSR 使用

```js
const OtherComponent = React.lazy(() => import("./OtherComponent"));

function MyComponent() {
  return (
    <div>
      <Suspense fallback={<div>Loading...</div>}>
          <OtherComponent />
        </section>
      </Suspense>
    </div>
  );
}
```

### Strict Mode （16.6）

[Strict Mode – React](https://reactjs.org/docs/strict-mode.html)

### Hooks

重点！

好吧，目前 16.7 还不能用，但未来几个月就可以用上这一突破功能。

有关文档：[Introducing Hooks – React](https://reactjs.org/docs/hooks-intro.html)

> 这次升级 React 的很大部分因素是 为了能使用到 Hooks

## How

> 简要记录升级过程

### 升级 react 包

选择升级的 npm 包
react
react-dom
以及重点选择了几个有关 react 的包

> 推荐使用 `npm-check` 去选择需要更新的包

### 替换生命周期

### 总览： LifeCycle 变更

- 未来将去除
  1.  `componentWillMount`
  2.  `componentWillUpdate`
  3.  `componentWillReceiveProps`
- 新生命周期
  1.  `static getDerivedStateFromProps`
  2.  `getSnapshotBeforeUpdate`

### 实施

- `componentWillMount` ——> `componentDidMount`
  **无痛变更**
  `componentWillMount` 存在的 问题： 1. componentWillMount 中 setState 一定会等到首次 render 之后才执行 reRender 2. SSR 会 call componentWillMount twice 3. 组件已 mounted，组件设计原则 4. Fiber 架构 导致 调用 componentWillMount 次数不确定

- `componentWillUpdate` ——> `componentDidUpdate`
  **无痛变更**
  与 `componentWillMount` 存在的问题差不多，也可能会多次执行

- `componentWillReceiveProps ——> static getDerivedStateFromProps + componentDidUpdate`

这个可能是修改起来比较麻烦的一个了，项目中使用的机会比较多，一般用作：

1. 根据 `Props` 变更与否来修改 `State`
2. `Props` 改变时去调用一些 `Func`，或者做出一些不会修改 `state` 的操作

> 与 `componentWillReceiveProps`不同，`getDerivedStateFromProps`在 Mounting 阶段也会执行

#### 针对第一种，更换方法：

`componentWillReceiveProps ` ——> `getDerivedStateFromProp `

```js
static getDerivedStateFromProps(nextProps, prevState) {
  // ...
}
```

> 注意这是一个 `static function`，也就是说，在内部使用 `this` 是指向类的，而不是实例，所以 `this` 并不是指向实例，意味着无法使用 `this.props/this.state`

**返回需要更新的 state（差异化更新，与现有 setState 方式一致，与 Hooks 不同）**
或是 null ：表示 state 不需要更新

```js
// before
componentWillReceiveProps(nextProps) {
  if (this.props.currentRow !== nextProps.currentRow) {
    this.setState({
      isScrollingDown: nextProps.currentRow > this.props.currentRow
    })
  }
}

// after
static getDerivedStateFromProps(nextProps, prevState) {
  if (nextProps.currentRow !== prevState.lastRow) {
    return {
      isScrollingDown: nextProps.currentRow > prevState.lastRow,
      lastRow: nextProps.currentRow
    }
  }

  // Return null to indicate no change to state.
  return null
}
```

通过例子：

以往我们依赖比较 `this.props.xxx` 与 `nextProps.xxx` 或者 `nextProps.xxx` 与 `this.state.xxx`是不行了。

在 `getDerivedStateFromProps` 中，需要将要比较的值也存到 state 当中，才能在之后通过 第二个参数 `prevState` 进行比较，比如 `nextProps.xxx vs prevState.xxx`

> 官方禁止了组件在 `getDerivedStateFromProps`中 去访问 this.props，强制让开发者去比较 `nextProps` 与 `prevState` 中的值，以确保当开发者用到 `getDerivedStateFromProps` 这个生命周期函数时，就是在根据当前的 `props` 来更新组件的 `state`，而不是去做其他一些让组件自身状态变得更加不可预测的事情。

> 返回值的机制和使用 setState 的机制是类似的 —— 只需要返回发生改变的那部分状态，其他的值会保留。

> WHY: 设计 `getDerivedStateFromProp`s 时，不加入一个 `prevProps` 参数，以方便比较
>
> 1. 首次加载，调用 getDerivedStateFromProps 时，prevProps 参数是空值，这就依赖我们后面的代码考虑到这一条件
> 2. 为了释放内存，保留之前的 props 是需要消耗内存的

#### 针对第二种，使用 `compomentDidUpdate`：

基于 `getDerivedStateFromProp` 的执行次数不可预测性，以及静态方法。
所有需要执行的 `side-effects`要放在 `compomentDidUpdate` 中去执行

基本上在旧有 `componentWillReceiveProps ` 中没有更新 `state` 的情况下，使用这个 methods 来代替是完全可行的，因为包括了我们需要用的到`prevProps`，并且 `componentDidUpdate` 内部可以访问 `this.props`，利用这两个我们可以作出对应比较

```js
componentDidUpdate(prevProps, prevState) {
  if (this.props.reqPending !== prevProps.reqPending && !this.props.reqPending) {
       this.props.history.push('/next-page')
  }
}
```

> 旧方法 `componentWillReceiveProps` 和新 `getDerivedStateFromProps` 方法都会增加组件的复杂性
> 强烈建议用这样派生状态前思考组件的设计模式。
> 官方建议：
> [You Probably Don’t Need Derived State – React Blog](https://reactjs.org/blog/2018/06/07/you-probably-dont-need-derived-state.html)

![image](https://user-images.githubusercontent.com/17287124/51101828-5ae85200-1817-11e9-9570-0f158b535a6c.png)

在 16.4 修复了 16.3 版本关于 `getDerivedStateFromProps` 调用的时机，加入了 组件 `自身触发setState` 以及 `forceUpate`

> 建议：
>
> 1. 保证无副作用 的 getDerivedStateFromProps
> 2. 计算受控值时，将传入的 props 与先前更新好的 state 进行比较
>    [React v16.4.0: Pointer Events – React Blog](https://reactjs.org/blog/2018/05/23/react-v-16-4.html#2-compare-incoming-props-to-previous-props-when-computing-controlled-values)

- `getSnapshotBeforeUpdate`
  很少情况会用到。

将在 DOM 被更新前调用，此生命周期的返回值将作为第三个参数传递给`componentDidUpdate`

### Context 替换

暂无替换，鉴于项目内使用到的地方比较杂，旧 Context API 方法在 17.0 之前还是可以正常使用

## Pains

升级遇到的痛点

1. 有很多组件在 `componentWillReceiveProps` 异步延时调用 setState …… ，而 `getDerivedStateFromProps` 中无法 异步更新 `state` ，所以做了大量工作去优化重写，实在优化不了的在 `DidUpdate` 去调用 `setState`（会造成多次渲染，但组件树不复杂的情况，忽略这些开销）

> Dan 回复过一个有关问题 ： [getDerivedStateFromProps for asynchronous setState · Issue #1147 · reactjs/reactjs.org · GitHub](https://github.com/reactjs/reactjs.org/issues/1147)
>
> [javascript - How to use React’s getDerivedStateFromProps with a setTimeout? - Stack Overflow](https://stackoverflow.com/questions/50115373/how-to-use-reacts-getderivedstatefromprops-with-a-settimeout)

2. 有很多子组件 `state` 初始值依赖于父组件，但却是在`componentWillReceiveProps` 方法中 去初始化，之后子组件 `setState` 替换掉 `state` 值。由于子组件 `setState` 不会调用 `componentWillReceiveProps`，但会调用 `getDerivedStateFromProps`，导致更新 `state` 值无效。
   解决：修改逻辑，加状态锁

3. 之前很多逻辑只依赖于 `componentWillReceiveProps` ，现在用 `getDerivedStateFromProps` 同 `componentDidUpdate` 去替换，导致逻辑分层，有些相似的逻辑要重复写（并不是说这里可以写个方法来重用，只是多了很多不必要的相似逻辑）

   > 期待未来版本 `Hooks` 将其统一。

4. 有些组件的逻辑 严重依赖 `componentWillReceiveProps` ，而 `getDerivedStateFromProps` 在 `mounting` 阶段也会调用，需要根据具体情况修改逻辑…

5. `basicPopup` 组件……
   此组件在 `submodule`，由于修改此组件，需要配合修改所有继承自它的 `Popup` 组件，而 这些组件并不全部在 `teachingSite`。也就是说，如果修改它，必须将依赖于它的所有项目升级 react 版本至 16.4 及其以上。暂时放弃此组件及其子类组件。（备注：在 17.0 之前，过去的生命周期可正常使用）

## Regret

1. basicPopup 及其子类组件还是有 未来将删去的 `componentWillReceiveProps`
2. Context 目前还没有变更至新 Context


TLA isn't a footgun anymore

Explanation

References