
## 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


记一次升级 React


## What is memoization?

`Memoization` 是一种优化技术，**缓存一些消耗性能的函数执行后的结果，以便在下次使用相同的参数调用相同函数时立即返回结果**。

> 许多编程语言中都有实现。
> `Memoization` 是使 递归 / 迭代函数 运行得更快的编程实践。

它在递归函数中特别有用，因为在递归时调用更可能使用相同的参数调用。以递归 `factorial` 函数为例：

```js
function factorial(num) {
  if (num === 1) {
    return 1;
  }
  return num * factorial(num - 1);
}
```

如果我们调用 `factorial(3)` 的函数，会连续调用 `factorial(3)、factorial(2)、factorial(1)`。

如果我们使这个函数有记忆性，再一次调用 `factorial(3)` 将直接返回已缓存的结果。

好处是，如果我们以此为基础，再次调用 `factorial(4)`，整个递归过程会简化很多，因为之前`factorial(3)`已经缓存，所以不需要进一步递归，可以直接使用已缓存的结果，节省性能，加快执行速度。

## 一个常见的 Memoization 函数：

```js
const memoize = (func) => {
  const cache = {};
  return (...args) => {
    const key = JSON.stringify(...args);
    if (cache[key]) return cache[key];

    const val = func(...args);
    cache[key] = val;
    return val;
  };
};
```

### 这个 Snippet 要点是：

1. memoize func 的返回值是一个 function
2. cache 可以缓存之前的值，因为返回的函数是一个闭包，会持久化访问变量。
3. 整个 memoize 函数必须为一个纯函数

## 常见的 memoization 优化主要用于递归：

```js
const memoFactorial = memoize((num) => {
  console.log('working for factorial(' + num + ')');

  if (num === 1) {
    return 1;
  }

  return num * memoFactorial(num - 1);
});

console.log(memoFactorial(3));

console.log(memoFactorial(4));

console.log(memoFactorial(4));
```

### 要点：

1. memoFactorial 函数以递归方式调用自身的 memoized 版本。
2. memoized 函数缓存了之前阶乘的值，这显着提升了性能
   - 就像这样： `factorial(6) = 6 * factorial(5)`

## 最后

React 在 16.6 推出了新的 API： memo

借鉴了 Memoization 的思想。

简单地说 memo 是一个高阶函数，在纯函数组件中使用类似于之前 `PureComponent` 的行为，浅比较 props 的改变来决定是否 rerender

```js
const ToTheMoonComponent = React.memo(function MyComponent(props) {
  // only renders if props have changed
});
```

> PureComponent works with classes. React.memo() works with functional components.

## Reference

> [Memoization - Wikipedia](https://en.wikipedia.org/wiki/Memoization#cite_note-Michie1968-3)


Permissions API 踩坑

Description

Permissions.query()

State Type

关于 Requesting Permissions

Notification

Navigator.getUserMedia

总结

1. 查看当前权限状态：

API:

2. 询问用户，获取授权权限：

API:

Reference