
## TL;DR

- Concurrent Mode is an opt-in feature
- New SSR Architecture
    - Behavioral changes to Suspense
- State updates in two categories
- Adding Strict Effects to StrictMode
- Built-in Suspense Cache
- Two separate rendering algorithms

## Not the Concurrent Mode anymore

Now，the Concurrent Mode is an opt-in feature，called Concurrent Rendering

这也是比较稳妥的渐进方案，毕竟 并发模式 带来的 breaking changes 可能会让社区头痛一阵，反而不利于 React 18 的推广

另外 Concurrent Rendering 不再是全局的改变 React 调度方式，而是需要搭配使用 `ReactDOM.createRoot` + `startTransition API`

“简单”来说，React 18 内部存在两种渲染算法：由新 feature 触发的更新会使用并发渲染，而对其他内容的更新会使用旧的渲染算法。在后面会解释这两种算法。

那么利用 Concurrent Rendering 细粒度控制能力，React 带来以下特性:

> 真实世界的使用方式，例如 [Next](https://github.com/vercel/next.js/blob/12c5693ef55709ee7380ee89a1d228cfdf06ca2d/packages/next/client/index.tsx#L509-L525)


<br>

## New SSR Architecture

> React Server Component 和 SSR 是不一样概念，React 18 也不会包含任何这个实验性 Feature

先来看一下常规 SSR 的瀑布流：

```js
fetch data (server) → render to HTML (server) → load code (client) → hydrate (client)
```
<br>

整个过程看起来很美好。在 Server 获取需要的数据（更快），将 Data 填充到 HTML 之后发送到 Client，Client 加载所需要的 JS 后进行 hydrate ，为页面添加交互。

但其中也有瑕疵：

1. 在 Server 端需要等到（所需） Data **全部**获得之后才能发送 HTML
2. 在 Client 端需要加载**完成**所有 JS 之后才能开始 hydrate
3. 在整个 Hydration 过程**完成**后，页面才能交互

React 新的 SSR 架构诞生的背景来自于此，让我们看看 React 是怎么解决的。

<br>
<br>

2018 年，React 提出了 Suspense ，从那时到 React 18 之前。Suspense 仅仅作为 Client 端的 Lazy-loading 方式被使用，但这显然不是它设计之初的全部目的

1. delayed transitions
2. placeholder throttling
3. SuspenseList

> 有多少人认为 Suspense 仅仅是一个 fancy loading spinner 😂

<br>

React 18 提出了 New Suspense，以取代 Legacy Suspense。

> 只是在内部讨论的代称。简单来说 React 18 的 Suspense 对比之前是更大的概念。

New Suspense 带来了更细粒度的控制机制，被 `<suspense>` 包裹的内容将变为一个独立单元，由 React 生态进行控制

<br>

而 React 关于 SSR 的 API 也有对应修改，其中增加了 `pipeToNodeWritable` ，以支持更细粒度的 Suspense 控制以及 Streaming of HTML

> 新的 SSR 架构源自内部 Fizz 架构：[Basic Fizz Architecture](https://github.com/facebook/react/pull/20970)

```tsx
import { pipeToNodeWritable } from 'react-dom/unstable-fizz';
```

简单来说，新 SSR 架构通过几个方式解决了之前的瑕疵：

1. Streaming of HTML：可以更早地传送 HTML，而不必等到所有 Data 全部获得之后。简而言之将传送 HTML 这个过程拆分，由编码去决定分成逐个顺序流进行（通过 `<Suspense>` boundaries）
    - 传送剩余的 HTML 将携带一个 tiny `<script>` 去操作替换的 Dom 节点
1. Selective Hydration：包含了 更早地进行 hydrate 以及 hydrate 时选择目标的优先级
    - 通过 React.lazy 将页面内容代码量较多的部分进行拆分，而页面的其余部分可以先进行 hydrate，待这部代码加载完成再进行相应的 hydrate
    - 一般来说需要整个 Hydration 完成之后，页面才能进行交互。但 React 将与用户交互的部分定义为高优先级，会优先进行 hydrate，从而让页面达到更早地可交互状态。

<br>

> 但这里可能会有一个问题，当页面 A 与 B 有联系，maybe Pub/Sub 之类的，A 已完成 hydrate，但 B 正在 hydrate。[相关讨论](https://github.com/reactwg/react-18/discussions/38)

> BTW，如果你对 SSR 的概念没有很好理解的话，可以翻阅 Dan 的这篇讲解 [New Suspense SSR Architecture in React 18](https://github.com/reactwg/react-18/discussions/37)

<br>

### Behavioral changes to Suspense

一个 suspended component `<ComponentThatSuspends>` 的兄弟节点 `<Sibling>` 的行为在 React 18 之后产生了变化

```js
<Suspense fallback={<Loading />}>
  <ComponentThatSuspends />
  <Sibling />
</Suspense>
```

- 在 React 17，`<Sibling>` 将会立即被渲染到DOM，触发相应的 effects/lifecycles（但节点会被 React 隐藏）

- 在 React 18，`<Sibling>` 不会被渲染也不会出发相应的 effects/lifecycles，直到 `<ComponentThatSuspends>` 获得了所需的数据

这是因为在之前的 React 版本中，有一个隐含的表现是 组件一旦开始渲染，最终都会完成渲染。

但这在 CM 下并不是这样，组件的渲染是可以被暂停的。而在 CM 之前的 Suspense 实现就包含了一个 React 会跳过 suspended component 去渲染它的兄弟组件，并渲染到真实 Dom Tree，然后在浏览器绘制之前，CSS 设置 `display: hidden` （:XD）。

这是一种兼容方案，而在 CM 下，这种 trick 就变得多余了，因为 React 可以暂停 Sibling 组件的渲染，直到 suspended data 完成。

<br>


## Automatic batching for fewer renders

`Batching` 其实是 React 优化性能的一个手段，将多个状态更新（groups multiple states updates）在单次渲染中批量处理

```tsx
function App() {
  const [count, setCount] = useState(0);
  const [flag, setFlag] = useState(false);

  function handleClick() {
    setCount(c => c + 1); // Does not re-render yet
    setFlag(f => !f); // Does not re-render yet
    // React will only re-render once at the end (that's batching!)
  }

  return (
    <div>
      <button onClick={handleClick}>Next</button>
      <h1 style={{ color: flag ? "blue" : "black" }}>{count}</h1>
    </div>
  );
}
```

这在 React 18 之前已经是一种默认行为，但有经验的 React 开发者应该知道，Batching Update 行为只会发生在触发源来自 React 的情况下

而 React 18 带来了 `Automatic Batching` ，意味所有的状态更新将会被 Batch，无论触发源是什么

这意味着 `Timeouts`/`Promises`/`Native events`/`Any other events` 内的状态更新行为将会与 `React events` 是同样的状态处理方式

`Automatic Batching` 对于使用 Hooks 的开发者来说并没有影响，因为 state 其实都是当时的 snapshot

对于 Classes 使用者来说，需要注意的一点是：

如果在 React Events 之外的情况进行状态更新，Class 组件会默认的**同步**进行更新状态，这意味着在 setState 之后将可以获取到更新完成后的状态

```tsx
handleClick = () => {
  setTimeout(() => {
    this.setState(({ count }) => ({ count: count + 1 }));

    // { count: 1, flag: false }
    console.log(this.state);

    this.setState(({ flag }) => ({ flag: !flag }));
  });
};
```

而在 React 18 下的行为，如果之前编写的逻辑对这部分有依赖就会有问题，在这个例子中，setTimeout 也将会被 bached，读取状态将会是和 Hooks 中一样的结果

有一个 escape-hatch 可以解决这部分 legacy 的问题，使用 `ReactDOM.flushSync` 去强制更新

```tsx
handleClick = () => {
  setTimeout(() => {
    ReactDOM.flushSync(() => {
      this.setState(({ count }) => ({ count: count + 1 }));
    });

    // { count: 1, flag: false }
    console.log(this.state);

    this.setState(({ flag }) => ({ flag: !flag }));
  });
};
```

<br>

## State updates in two categories

React 18 将反应 UI 的状态更新分为两种:

1. Urgent updates 紧急更新，比如 Typing/dragging/hover
2. Transition updates 过渡更新，比如 UI 之间的过渡状态

简单说 React 区分不同优先级的 UI 状态更新，是为了让页面反馈在实践取舍下更加自然。
`startTransition` 可以避免当组件再次被 suspends 时隐藏已存在的内容。换句话说就是 在重新获取新数据时同时展示旧数据的策略模型

```jsx
import { startTransition } from 'react';
// or import { useTransition } from 'react';

// const [isPending, startTransition] = useTransition();

// Urgent: Show what was typed
setInputValue(input);

// Mark any state updates inside as transitions
startTransition(() => {
  // Transition: Show the results
  setSearchQuery(input);
});
```

<br>

## Adding Strict Effects to StrictMode

简单说 StrictMode 支持了 double-invokes effects （mount -> unmount -> mount），方便开发者提早发现 Effect 中逻辑的缺陷

> 值得注意的是: double-invokes effects 指的是调用 Effect 后，要先清理第一次的 Effect 后再调用第二次 Effect

<br>

## Built-in Suspense Cache

使用起来就像这样:

```tsx
<>
  <Cache>
    <Toolbar>
        <CurrentUserProfilePic />
    </Toolbar>
  </Cache>
  <Cache>
    <MessageThread>
      <CurrentUserProfilePic />
      <CurrentUserProfilePic />
    </MessageThread>
  </Cache>
</>
```

简单说 Cache 允许了 状态 和 UI 的不一致性，就像是目前很流行的 Data-fetching Lib 所基于的 stale-while-revalidate 思想

在工作中我也有过类似的需求，最后利用了 `react-query` 的 cache 机制实现了跨组件的状态同步。但这局限在 state 来自于 Data-fetching，而 Suspense Cache 看起来要将所有的 state 进行缓存。

目前 React 18 alpha 是没有包含 Cache 的，应该是不会被包含在正式的 18版本内，是一个早期的实验性 Feature

> 有点期待 [@sebmarkbage](https://twitter.com/sebmarkbage) 的分享 "Here and There"


## Two separate rendering algorithms

开头提到了 React 18 内部具有两种独立的渲染算法

- 并发渲染是 React 18 主要的算法。通过使用 `startTransition` 包裹的更新、使用 `useDeferredValue`、`<SuspenseList>` 以及 resloved 的 `<Suspense>` 来触发。这是一种 interruptible 算法，渲染组件树的过程中遇到 suspends 的组件，将跳过这部分（渲染 fallback 内容）继续渲染。同时每隔 5ms 交还控制权给浏览器（查看是否有更高优先级任务需要去做），当渲染结束时，渲染算法去决定及时更新到屏幕 or 稍后更新。


- 同步渲染是并发渲染的不可中断版本，意味着一旦开始渲染过程将不会被停止，直到更新到屏幕（这在内部被称为 Urgent updates）。这就是 React 应用于所有“其他”更新的算法。


> However, there’s a nuance. If you haven’t yet migrated to createRoot and are using the deprecated render which warns, you get the third algorithm:
> Temporary synchronous algorithm with additional legacy behavior. It’s the same for all updates. New features don’t work at all in it (they are ignored—for example, all transitions become urgent). This one almost exactly matches what React 17 and earlier are doing. It has no automated batching. It also does many weird contortions for `<Suspense>` specifically in order to preserve all the legacy guarantees (like that `UNSAFE_componentWillMount` corresponds 1:1 to `componentDidMount`). It prevents us from throwing away suspended trees, and prevents us from fixing a number of common application-level Suspense bugs.


## Conclusion

React 18 所包含的内容是这几年 React Team 的主要工作内容，CM 作为一个 opt-in 的 feature 被正式引入，与之而来的借助 CM 能力的各种特性，可以看到大多数特性都是围绕 UX 进行设计和作出取舍。
在 React 18 未来 release 之后，React 的重心将转向混合渲染，进一步提升 UX。

## Reference

- [The Plan for React 18](https://reactjs.org/blog/2021/06/08/the-plan-for-react-18.html)
- [Automatic batching for fewer renders in React 18](https://github.com/reactwg/react-18/discussions/21)
- [Replacing render with createRoot](https://github.com/reactwg/react-18/discussions/5)
- [React DOM Event Priority](https://github.com/facebook/react/blob/a8a4742f1c54493df00da648a3f9d26e3db9c8b5/packages/react-dom/src/events/ReactDOMEventListener.js#L294-L350)
- [Behavioral changes to Suspense in React](https://github.com/reactwg/react-18/discussions/7)
- [New feature: startTransition](https://github.com/reactwg/react-18/discussions/41)
- [Upgrading to React 18 on the server](https://github.com/reactwg/react-18/discussions/22)
- [New Suspense SSR Architecture in React 18](https://github.com/reactwg/react-18/discussions/37)
- [Keeping browser interactive during hydration](https://github.com/reactwg/react-18/discussions/38)
- [useMutableSource](https://github.com/reactjs/rfcs/pull/147)
- [Built-in Suspense Cache](https://github.com/reactwg/react-18/discussions/25)
- [Add built-in Suspense cache with support for invalidation (refreshing)](https://github.com/facebook/react/pull/20456)
- [Adding Strict Effects to StrictMode](https://github.com/reactwg/react-18/discussions/19)

Now，the Concurrent Mode is an opt-in feature，called Concurrent Rendering...

Talking about React 18



> Grater 目前在比较初期的阶段，[代码已开源](https://github.com/nanyang24/grater)，可以在[这里](https://nanyang24.github.io/Grater/)体验

> Hi，首先在开始之前，我得承认，我并没有 CS 教育的经历。通常这句话的后面一定有转折语句，我想这里还是不要有了。所以虽参考多个领域内概念，但落地总体还是偏向于实用主义。

<br>
<br>

在专注前端一段时间后，可能会发现工具链中有很多都包含基础的 Parser，比如 TypeScript 的

[Parser](https://github.com/microsoft/TypeScript/blob/master/src/compiler/parser.ts)，React 使用的 Parser 是 [Acorn](https://github.com/acornjs/acorn) 以及 [Acorn-JSX](https://github.com/acornjs/acorn-jsx) ，之前是使用 Esprima 的 [fork 版本](https://github.com/facebook/esprima)，ESLint 也是一样，只是改了名字叫 [Espree](https://github.com/eslint/espree)，而 Babel 使用了自己的 [Parser](https://github.com/babel/babel/tree/master/packages/babel-parser)。

可能会有个疑惑是为什么不利用 Lex/Yacc 来快速实现，而是选择 CP 值有些低的手写方式。有实现一个JS AST Parser 的想法来自于 “我想与 JS 更近一点”，很难描述这种情感，通常人们可能普遍认为这是一种自我描述性质的解释。在这个过程中看了很多类型的 Parser 实现，由衷感谢这些开源巨人们，没有这些作为参考，绝对没有这篇文章以及 Grater。

<br>
<br>

Grater 是一个输出符合 ESTree 定义结构 AST 的 ECMAScript Parser，目前基本实现了大部分 ES5 所包含的定义，初期大目标是追上最新 ES 标准实现。在输入符合语法规则的代码前提下，解析出 AST，没有做 Tokens 的输出（也是因为 Tokens 并没有一个官方规范标准），以及更加复杂的错误恢复机制

使用 TS 来书写 Grater 是为了尽量减少一些心智负担，能够预想到这个项目不会很小，增加一些必要的约束可以提高效率，也能利用 ES-Tree 的类型定义完善结构

实现一个最普世的 AST Parser，流程如下：

`SourceCode ~~ Tokenizer ~~> Token Stream ~~ Parsing ~~> AST`

<br>

简要来说，源码将被 `Tokenizer` 后形成 一长串不同类型的 `Token` 字节流，以便于我们按照规范的定义，在 `Parsing` 阶段解析相应的语法语句结构，形成特定的 `AST` 结构。

> 我们目标是产生符合标准的 AST，也就是要符合 [The ESTree Spec](https://github.com/estree/estree)，而解析方式也尽量按照 ECMAScript® Language Specification 中的描述去实现。


<br>
<br>

## 阶段 1 : Tokenizer

`Tokenizer` 词法分析 (Lexical Analysis)，也就是常说的 分词 ，将要解析的源解析为逐个符合特定语言规则的符号，这个过程通过实现 DFA 做具体的分词工作

> Lexer / Scanner 都是在描述这个阶段

### 实现分词的方式

根据语言的词法规则，标记出一串字符中的不同类型 Token

这里我们简单 parse 一个 stream：`age ≥ 26`

![!img](http://cdn.nanyang.io/images/age%3E=26.png)

> Identifier、Number、>= 都是终结符，终结符都是词法分析中产生的 Token。
> 而那些非叶子节点，就是非终结符。
> 文法的推导过程，就是把非终结符不断替换的过程，让最后的结果没有非终结符，只有终结符。

利用实现好的 DFA，在不同的状态进行转移，解析出 Token

- 完整的语法词法分析器只是一个具有完善状态和转移路线的 FSA
- 为了简化 Token 的解析，所以 Token 通常会采用正则文法（如名称、运算符、常量、注释）

<br>

### 为 Token 分配状态

在之后的 Parsing 过程中会经常使用到 判断当前 Token 是否符合一类定义的情况

比如: 判断当前 Token 是否为 `Keyword` 或者 `Pattern`

我们可以利用 `位运算` 进行状态的分配 ([压缩状态](http://mark-story.com/posts/view/using-bitmasks-to-indicate-status))

在字符定义中，我们可以为字符配置特有的状态

```jsx
/* Variable declaration */
VarKeyword = 71 | IsKeyword,
LetKeyword = 72 | IsKeyword,
ConstKeyword = 73 | IsKeyword,

LeftBrace = 12 | IsPatternStart, // {
LeftBracket = 19 | IsPatternStart | IsPropertyOrCallExpression, // [
```

```jsx
// will match `{` and `[` or Keyword
if (parser.token & Token.IsPatternStart || parser.token & Token.IsKeyword) {
	// todo
}
```

<br>


### 判断 Keyword 的方式

语言都有各自的保留字，比如 `let`，`function`，`true`/`false`

查看了 Esprima 的[谓词实现](https://github.com/jquery/esprima/blob/45c9ab14d96f7f7fa88333fdd897487a8c20082f/src/scanner.ts#L348)，觉得还可以有简约的实现

```tsx
private isKeyword(id: string): boolean {
  switch (id.length) {
      case 2:
          return (id === 'if') || (id === 'in') || (id === 'do');
      case 3:
          return (id === 'var') || (id === 'for') || (id === 'new') ||
              (id === 'try') || (id === 'let');
      case 4:
          return (id === 'this') || (id === 'else') || (id === 'case') ||
              (id === 'void') || (id === 'with') || (id === 'enum');
			// ...
      default:
          return false;
  }
}
```

由于我们可以知道当前 Token 的字符值，这里简单使用了 HashMap 取值的方式：

```tsx
function scanIdentifier(parser: IParserState): Token {
	// ...
	//
  return mapKeywordTable[parser.tokenValue] || Token.Identifier;
}

...
// Keyword hash-map Table
export const mapKeywordTable: { [key: string]: Token } = {
  this: { value: Token.ThisKeyword },
  function: { value: Token.FunctionKeyword },
  if: { value: Token.IfKeyword },
  return: { value: Token.ReturnKeyword },
  var: { value: Token.VarKeyword },
  else: { value: Token.ElseKeyword },
}
```

> BTW: 正则判断并没有优势


<br>
<br>

## 阶段 2 : Parsing

`Parsing` 语法分析 (Syntactic Analysis)，在这个阶段将在 Tokenizer 的基础上进行语法结构的识别

Grater 采用的解析方式是常见的 LL(k) Parser，是一种 自顶向下的 Parser

其中两个 L 的意思分别是：`Left-to-right` , `Leftmost derivation`


语句的规则通常 左边是 非终结符(Non-terminal)，右边是 产生式(Production Rule)，这种表达方式是 [上下文无关文法](https://en.wikipedia.org/wiki/Context-free_grammar)(Context-free grammar)，在解析的过程中，非终结符将被其产生式替换，直到最后全部变成 终结符(Terminal)，也就是 Token，这一系列的过程叫做 `Derivation` （`Leftmost derivation` 指总是先把左边的非终结符展开，也就是从最左的非终结符开始推导，而且是深度优先）

<br>

其中 `Recursive Descent Parsing` 的实现其实很简单，非常的直观

> 实际上，JS 语法并不是完全纯粹的 Context-free grammar
> 而递归下降的实现里可以做到超越 CFG，在 Recursion func 中可以传递 context，在有需要上下文解析的情况里用到，以及丰富错误信息


<br>

### 消除左递归 left recursion

由于 Grater 是没有 [Backtracking](https://en.wikipedia.org/wiki/Backtracking)，那么就需要分析时对每个文法做正确的展开

但遇到左递归的文法，就会有问题，解决的方法通常是将左递归转化为等价的右递归形式

例如在 Binary Expression 的词法规则中，产生式的第一个元素是它自身，那么程序就会无限地递归下去，这种情况就叫做左递归。

比如 加法表达式的产生式中有一条是 “加法表达式 + 乘法表达式”

我们用 `2 + 3` 这个加法表达式来举例

 ECMAScript Language Specification 中加法表达式的定义式:

*[AdditiveExpression](https://tc39.es/ecma262/#prod-AdditiveExpression)* 

- *[MultiplicativeExpression](https://tc39.es/ecma262/#prod-MultiplicativeExpression)*
- *[AdditiveExpression](https://tc39.es/ecma262/#prod-AdditiveExpression)* **+** *[MultiplicativeExpression](https://tc39.es/ecma262/#prod-MultiplicativeExpression)*
- *[AdditiveExpression](https://tc39.es/ecma262/#prod-AdditiveExpression)* **-** *[MultiplicativeExpression](https://tc39.es/ecma262/#prod-MultiplicativeExpression)*

*[MultiplicativeExpression](https://tc39.es/ecma262/#prod-MultiplicativeExpression)*

- *[ExponentiationExpression](https://tc39.es/ecma262/#prod-ExponentiationExpression)*
- *[MultiplicativeExpression](https://tc39.es/ecma262/#prod-MultiplicativeExpression) [MultiplicativeOperator](https://tc39.es/ecma262/#prod-MultiplicativeOperator) [ExponentiationExpression](https://tc39.es/ecma262/#prod-ExponentiationExpression)*

接下来，我们只保留关键信息，简化的 [BNF](https://en.wikipedia.org/wiki/Backus%E2%80%93Naur_form) :


```js
Additive: 

    Multiplicative

    | Additive + Multiplicative


Multiplicative: 

    IntLiteral

    | Multiplicative * IntLiteral
```

非终结符通常只用了一个大写字母代表，通常可简写为：

```tsx
A -> M 
   | A + M 
   | A - M
```

我们的 Token 串是 `2 + 3`，来进行匹配规则

1. 应用第一条规则 A -> M，2 + 3 不是 M 表达式，转移到使用 A -> A + M 的方法匹配
2. A + M 将从 A 开始推导，重复了第一步的操作，导致了 infinite loop

- 如果对第二个步骤不理解，比如认为 2+3 应该符合 A + M 这个规则
这样认为是因为本能的使用了广度优先，而我们的 Parser 是依照深度优先

然后可以通过转换文法消除左递归

A: M | M + A

再进行推导就消除了之前的循环

> 其实 左递归的问题 与 运算符优先级也有关联

<br>
<br>

### Operator Precedence 运算符优先级

优先级是通过在语法推导中的层次来决定的：优先级越低的，越先尝试推导。
而对应在 AST 树中，层次越深，优先级越高

例如：`1 + 2 * 3` 产生的 AST 结构为

```json
{
  "type": "Program",
  "sourceType": "script",
  "body": [
    {
      "type": "ExpressionStatement",
      "expression": {
        "type": "BinaryExpression",
        "left": {
          "type": "Literal",
          "value": 1
        },
        "right": {
          "type": "BinaryExpression",
          "left": {
            "type": "Literal",
            "value": 2
          },
          "right": {
            "type": "Literal",
            "value": 3
          },
          "operator": "*"
        },
        "operator": "+"
      }
    }
  ]
}
```

Grater 采用 [Precedence climbing method](https://en.wikipedia.org/wiki/Operator-precedence_parser#Precedence_climbing_method) 实现高效的运算符优先级解析。
如果当前运算符的优先级小于前一个运算符，则提前返回叶子节点。并将 高优先级运算符 左右两边的节点合并为一个 `BinaryExpression`

还有几个特殊的情况需要处理：
1. 括号优先于所有运算符
1. `^` 是右关联的，而所有其他二进制运算符是左关联的

<br>

> 这里提及两个解决优先级相关的算法
> 1. [Precedence climbing](http://www.engr.mun.ca/~theo/Misc/exp_parsing.htm#climbing)
> 2. [Shunting-yard algorithm](https://en.wikipedia.org/wiki/Shunting-yard_algorithm)


<br>


## Conclusion

如果你有想法打算尝试写一个 Parser，我的建议是 Just write it，你可以先不用管那些固有理论，着手去实现它，在实现过程中不断优化，遇到问题再依据理论加以解决


> *Sometimes you gotta run before you can walk — Iron Man*


### Contribution
> 为 Grater 实现更多的功能及识别更多的语法

如果你有兴趣贡献代码給 Grater，让它变成更完善的 Parser，非常欢迎结合你的思考来实现 Grater 目前所需的功能点，在[这里](https://github.com/nanyang24/Grater/blob/master/README.md#-feature-to-do-list)可以查看

## Reference

1. [Acorn: Alternative, faster React.js JSX parser]([https://rreverser.com/gh-acorn-jsx/](https://rreverser.com/gh-acorn-jsx/))
2. [Operator-precedence parser]([https://en.wikipedia.org/wiki/Operator-precedence_parser](https://en.wikipedia.org/wiki/Operator-precedence_parser))
3. [LR parser]([https://en.wikipedia.org/wiki/LR_parser](https://en.wikipedia.org/wiki/LR_parser))
4. [LL parser]([https://en.wikipedia.org/wiki/LL_parser](https://en.wikipedia.org/wiki/LL_parser))
5. [Top-down parsing]([https://en.wikipedia.org/wiki/Top-down_parsing](https://en.wikipedia.org/wiki/Top-down_parsing))
6. [Recursive descent parser]([https://en.wikipedia.org/wiki/Recursive_descent_parser](https://en.wikipedia.org/wiki/Recursive_descent_parser))
7. [Left recursion]([https://en.wikipedia.org/wiki/Left_recursion](https://en.wikipedia.org/wiki/Left_recursion))
8. [NFA]([https://en.wikipedia.org/wiki/Nondeterministic_finite_automaton](https://en.wikipedia.org/wiki/Nondeterministic_finite_automaton))
9. [Context-free grammar]([https://en.wikipedia.org/wiki/Context-free_grammar](https://en.wikipedia.org/wiki/Context-free_grammar))

实现一个 ECMAScript Parser 需要做的事情


最近在工作中 review code 以及看到几个小伙伴的提问

看到的一些现象是:
1. `Imperative Programming` 处理状态

2. 违反最佳实践去实现状态更新

3. 实现业务功能前缺乏对技术实现的深度思考

4. ...

前端本质是人机交互层，操作处理的是状态，如何处理好状态是问题所在

那么怎样才算是处理好的状态?

**「理解业务需求下的最佳路径状态更新实现是目标」**

我的体会是感受 `状态` 像水流一样经由树上的枝节(组件)流淌而下（尽管有点诡异

枝节上当时经过水流的状态，水纹/涟漪/湍急与否，都应该属于那个时刻的状态，一些 Imperative Programming 就像是向水中抛出了石头，之后你需要做的还有让属于枝节的水流恢复正常的状态，当业务复杂度上一个层级之后，状态之间的恢复操作会变得异常臃肿和难以维护

不同枝节的水流会汇入主枝干，状态和状态之间也会互相影响，也就是 `Derived State`，思考状态之间的联系，大部分需求场景都可以通过这样的方式轻松解决，设计参差交错的枝节组合，能更好的优化性能和不必要的渲染

枝节上永远都有水在流淌，有时候我们太过关心状态的更新，而忽略了状态的时效性（例如状态的缓存），其实我们需要拿到的仅仅满足需要的状态

深度理解业务场景，有助于实现前在脑海中描绘出这颗状态之树，状态之间的联系，以及各个枝节的组织关系和状态依赖

> React Hooks 以后，React 终于有了点 reactive 的味道（本质还是 Stale-while-refresh

![image](https://user-images.githubusercontent.com/17287124/111597060-cae42f80-8808-11eb-8030-0a95f399de8f.png)


#### 最后推荐一些采用相似思想的工具和体会方式:

1. [Vue Reactivity in Depth](https://v3.vuejs.org/guide/reactivity.html#reactivity-in-depth)
2. 受 Stale-while-revalidate 启发的 Data-fetching 工具 [SWR](https://swr.vercel.app/)
3. [Before You memo()](https://overreacted.io/before-you-memo/)
4. [Algebraic Effects for the Rest of Us](https://overreacted.io/algebraic-effects-for-the-rest-of-us/)
5. [The introduction to Reactive Programming you've been missing](https://gist.github.com/staltz/868e7e9bc2a7b8c1f754)
6. [Netflix JavaScript Talks - Real-time Insights powered by Reactive Programming](https://www.youtube.com/watch?v=uODxUJ5Jwis)
7. [Netflix JavaScript Talks - Async JavaScript with Reactive Extensions](https://www.youtube.com/watch?v=XRYN2xt11Ek)

Reactive State


该为这混乱的一年画上句号了。

2020年以一场 Pandemic 为开局，注定是特别的一年。

### 生活

因为疫情，春节行程变得不同寻常，那段日子不断查看每日疫情报告，返工的日期也不断延后。因为女朋友当时还在北京工作，她就提前返京了，我刚好需要从北京转机回深圳，也就“想尽办法”的先到了北京（机票被取消3次后抓住了每周只有一班的绿皮车）。

到了北京之后，国内疫情形势加重，大多数公司都开始 WFH。

<br /><br />

在北京租的房子在西郊线的茶棚，离颐和园特别近。和市区的喧嚣不同，这里就像日本的乡下，能让心灵放松下来

<figure>
  <img
  src="https://cdn.nanyang.io/images/6B2A4E04-5081-42AF-83C4-0025EEB35796.jpeg"
  alt="茶棚站旁边的铁轨">
  <figcaption>茶棚站旁边的铁轨</figcaption>
</figure>

<figure>
  <img
  src="https://cdn.nanyang.io/images/5AFD4955-8737-49E2-868D-495F8A54DB82.jpeg"
  alt="夕阳下的车站">
  <figcaption>夕阳下的车站</figcaption>
</figure>

<figure>
  <img
  src="https://cdn.nanyang.io/images/726CFACE-FFBA-4D48-9ADD-82D30F94DD2D.jpeg"
  alt="时常会去逛逛旁边的颐和园">
  <figcaption>时常会去逛逛旁边的颐和园</figcaption>
</figure>

<figure>
  <img
  src="https://cdn.nanyang.io/images/B7F3CB58-DC24-4E09-BBA3-788E8ACF8824.jpeg"
  alt="小区旁边的公园">
  <figcaption>小区旁边的公园</figcaption>
</figure>


<br />

休息日会去商业中心，那时候北京属于半封城状态，繁华地段也是人很少

在西单大悦城的 Apple Store 见到了 Pro Display XDR 和 Mac Pro 的实物

![image](https://cdn.nanyang.io/images/E95AB0B0-9CB3-4789-B9FA-710FF6B2F83F.jpeg)

每年 Apple 都会邀请知名导演拍摄一部有关春节味道的短片，今年是《女儿》

[Chinese New Year — Daughter](httpss://www.youtube.com/watch?v=bvtwWhKdxhM)

其实我一直对春节期间的归途部分，充满了兴趣，紧迫感和兴奋感和很多情绪杂糅在一起

<figure>
  <img
  src="https://cdn.nanyang.io/images/82466D87-B2E8-41FE-ACF7-DC8597A022E4.jpeg"
  alt="突然就没有密恐了">
  <figcaption>突然就没有密恐了</figcaption>
</figure>


<br /><br />

转眼陆续返工，我们相继回到了深圳。

这是我当初选择的城市

即使已经如此熟悉这个城市，也不能消散我对它的喜爱，这座有海有山的城。

日常虽然忙碌，倒也充实。通勤时都会思考一些或大或小的事情

在路途中遇到之前便见过的陌生人，那种感觉很奇妙，甚至有点惊悚，仿佛往前走的只有时间

<br /><br />

今年生日礼物收到了 明日香 的二号机，来自贴心的GF，完成了初号机二号机的大集合！

![image](https://cdn.nanyang.io/images/B54B192C-5A78-430F-9246-F40E58EE254F.jpeg)

<br /><br />

墙上也多了两幅框画

- [The Chart of Cosmic Exploration](httpss://popchart.co/products/the-chart-of-cosmic-exploration)

描绘了人类 56 年勇敢探索宇宙的探测器轨道（Luna 2 in 1959 to DSCOVR in 2015）

- [SpaceX Dragon](httpss://www.spacex.com/vehicles/dragon/)

SpaceX Dragon 飞掠地球的场景

![image](https://cdn.nanyang.io/images/C391D6B6-37D4-4BE2-A613-7AB672EA3B81.jpeg)


<br /><br />

因为疫情的关系，5月东京之行被迫取消，索性专注在了国内，也刚好去一些之前感兴趣但没有成行的地方

比如 重庆 和 成都

在 5D 的重庆，会看等高线是必修课hhh，有着在其他城市绝无仅有的体验。还有遍地都是又爱又辣的火锅，推荐一定要去感受下。

重庆夜景非常容易出片，加上十月份常见的大雾，后期拉下曲线就有 Cyberpunk 的味道

![image](https://cdn.nanyang.io/images/86D85E14-B18A-4560-86DD-13A67D47FA3E.jpeg)

相比与重庆的喧闹和特别，几百公里外的成都截然不同

成都的第一感受是舒适，安静。很适合我这样做行程只做50%的人。来之前也不会想到太古里还不错，与之相连的大慈寺闹中取静，香火隆盛。

计划中还有去附近的湖边野营，刚好感受一下 “蜀道” 的魅力，其中有一段在山上，迷雾笼罩仿佛驾驶在仙境

> BTW 未来一定要去 Nürburgring 体验一下
![image](https://cdn.nanyang.io/images/Nürburgring.png)

在经历曲折盘山路到达雅女湖后才得知因为雨水丰沛，导致湖水暴涨，淹没了原本的露营区域，计划宣告失败

<figure>
  <img
  src="https://cdn.nanyang.io/images/B1FB3412-7658-4AEC-809C-144DD4ABBB01.jpeg"
  alt="从酒店房间望去的雅女湖">
  <figcaption>从酒店房间望去的雅女湖</figcaption>
</figure>

<br /><br />

今年看了很多 YouTuber 制作的内容，还有博客，很喜欢在屏幕前的时光，网络让我有随时触摸到世界任何地方能力的错觉。从他们书写的字里行间，视频的每一帧画面，感受不同个体散发的美好。

另外罗列一些值得记录的事情

1. 对 Racing line 的理解加强，在东莞卡丁车场练习，还在广州试玩了直驱模拟器，以后打算在家搞一套
2. 在川崎店里试了 Ninjia 400，基于深圳的禁摩政策还在犹豫中
3. 哈尔滨滑雪🏂，喜欢掌控平衡的感觉，希望明年有机会去日本滑粉雪
4. 回内蒙古看望我的父母
5. 见了GF的父母
6. 逛2020广州车展，第一次去车展，没有预想的好，而且都是常见车，花钱去4S店感觉……
7. 扛着三脚架在雨天拍摄重庆夜景，一次难忘的经历！
8. 跟随 TPA 拍摄人像，Key 是与模特的沟通，传达摄影师的意图
9. 更新了2米长的实木桌和人体工程学椅，氛围灯也上了，对于热衷桌面文化的人，简直不要太开心
10. 今年本打算购置电脑，其实是去年年底就有这个想法了，奈何订了一台鸽了一年多的机箱，到现在也没收到。后面就开始等新款 iMac 了，目前看样子还要继续等下去。
11. 剧看的不多，刷完了 The Queen's Gambit 、The Crown 和 Drive To Survive 1 & 2
12. 借着 Mini 4WD 在深圳的比赛，完成童年的没做的事情，顺势动手做了一辆当下时代的MS避震车
13. 对电子产品克制了许多，考虑许久CP值才会真的下单，今年入了
    1. iPad Pro 2020，旅行剪辑修片，日常GF画画看书
    2. Sigma 24-70mm F2.8 DG DN，终于有一颗变焦头了，大爱
    3. Samsung  SSD T7 Touch，旅行快速存储方案
    4. Dyson V11 Torque Drive，如同洗碗机般重要的存在
14. 投资收益不错，得益于科技股在2020年普遍高涨，未来还是一如既往价值投资
15. ......

其实还有太多想分享的东西，一不小心又写成分享文，以上的内容有空会写成详细文章

<br />


### 职业

我目前的职业是 Front-End Engineer 

今年是 JS 诞生25周年，也是我的25周年。是的，我和 JS 同岁😂

去年9月份离开了 Bellcode，有很多不舍，经常回忆（现在还留着很多当时同事的恶搞照片hhh）。

紧接着10月份来了 CODING，进入了代码托管部门。说来也巧，在大学的时候使用过 CODING 的产品，当时也不会想到日后会有更多的缘分。

业余时间正在成为~~精读 ECMAScript 规范的 language lawyer~~，在做一个完整解析 ES 的 Parser，第一个版本应该会实现了 ES5 的绝大部分语法，Release 尽力不鸽的在~~明年3月（要补的测试用例太多了，实在头大）~~

也顺手做了几个有关 Router 的 lib。另外一直在优化这个网站的体验，有空基于 Server Component 玩一下。

<br />

### Next

- [Do One Thing and Do It Well](httpss://en.wikipedia.org/wiki/Unix_philosophy)
- 博客的技术向，多借鉴 Netflix Tech Blog
- 做技术要自信，做人同理
- 把生活过得有趣
- 健康第一位

回顾一年中发生的事情，如今看来更像是一段段剪影

2020 Fragment


> [如何看待 React Server Components？ - Nan Yang 的回答 - 知乎](https://www.zhihu.com/question/435921124/answer/1640062154)

真实世界的应用往往是一部分都是“静态”的，而另一部分都是“动态”的，单一的解决方案覆盖不了大部分 Case

Server Components 的出现，在配合之前的 Client Components，可以达到纯 CSR 的动态性和纯 SSR 的静态内容快速渲染的效果（理想）

当然 hydration 这事没有 React 也能做，但是统一语言和生态应该算个(小)创新

1. 将 Data-Fetching 这一阶段放在服务端去做
2. 将非交互相关的第三方依赖放在服务端处理，减少客户端的 bundle size
3. Server 端 React 返回的是一种 [streaming protocol](https://news.ycombinator.com/reply?id=25499311)（描述 UI 的 Data），目的之一是渲染 Server Component 可以保留客户端组件的状态
4. 服务端和客户端可以共享一些组件，延迟加载一些由用户决定的客户端交互功能

### 目前看起来还有很多点可以谈:

1. 目前 Server Components 的 refetching 是全量的
2. 路由集成，目前看起来是交给 Next.js 这样的 Framework 来做了，也可能利用 Context
3. 打包这一阶段可以做的事，比如真的真的要以后缀区分不同端组件吗
4. Server 和 Client 未来可以做共享受限状态
5. 支持开箱即用的 SSG，这一点应该比较简单，Server Components 运行在服务端，配置服务端输出为 HTML
6. Server 端限制在 Node（当然可以用 rust/等 重写这部分，但 Client 可能没办法直接复用）
7. 预计未来可能会有很多围绕 Server Components 的 lib
8. 真正世界，项目落地的成本

However，Server Components 概念上还是很有想象力的，可以开脑洞想一个落地的例子


Server Components


> [React 的 Concurrent Mode 是否有过度设计的成分？ - Nan Yang 的回答 - 知乎](https://www.zhihu.com/question/434791954/answer/1636434930)



如果按照题主对于 过度设计 的定义，我觉得 Concurrent Mode 是没错，毕竟相应 FB 的需求是 React 团队要考虑的，另外基于 React 近年的发力趋向，他们对于 UX 方面的考量显然变得更为重要。

> 体验一下 新版 [Facebook](https://www.facebook.com/)

我谈谈个人的理解。

其实 Concurrent Mode 带来的是两个维度的改变，第一是 CPU bound，第二个是 I/O bound。

#### 第一点：CPU bound

各家的实现差异对应都有不同的优化措施，而对于 React 这种本就在编译期做不了什么优化的，能做的选项就更少了，那么在 runtime 去协调不同优先级任务的执行就显得格外重要。

#### 第二点： I/O bound

这是目前 UI lib 在提供选项所缺失的，那么缺失就需要业务开发者去实现，React 开发者想必并不陌生各种各样的 conditional statements，无论是在 JSX 还是封装藏在各种地方。
其实这样也还好，问题是并不能做到极致，业务开发者是很难处理组件层级优先级和优先渲染必要组件，更别说前置处理未来将会用到的组件。往往结果就是懒得做了，if-else 下班打卡，用户这边也就多被恶心了几秒。

React 的 Intentional Loading Sequences 是根据 [最小可觉差](https://en.wikipedia.org/wiki/Just-noticeable_difference) 理论带来的进一步实现，在框架层面去处理上述提到的问题（也需要业务开发者在实现上去配合）。

不过框架来做这些事，是真的难，调和适应大部分应用场景这一点就很难，还有很多边界情况的取舍。光是看到关于一个 JND 的[时间描述](https://github.com/facebook/react/blob/99554dc36fa9f5ef29b75dd59836dcc720d831b9/packages/react-reconciler/src/ReactFiberWorkLoop.new.js#L2819)，就改动了好几版，更别说 [Fiber 优先级的改动](https://github.com/facebook/react/pull/18796) 。

> 其实我很好奇 Vue 的 Suspense 可以达到的效果

#### 最后说说 DX 方面吧

React 毫无疑问将很多事留给开发者，数数 Hooks 的 api 中关于 memoization 的有多少个；写对 deps Array 你需要了解 Fiber 的基本运作，SO 上有多少关于 Hooks 的提问。讲真，对于一般开发者，心智负担不是一般的重。

当初 Vue 在提出 [Function-based Component API](https://github.com/vuejs/rfcs/pull/42)（也就是现在的 [Composition API](https://github.com/vuejs/rfcs/pull/78)）时，我就立刻（其实换个说法是后知后觉）觉得 类 React Hooks 这套 interface 太适合 Vue 这种 reactivity tracking 的思维模式了

但话又说回来，用户群体也是 React 能决定走向实现 Concurrent Mode 这条路的底气之一吧。


Is Concurrent Mode over-engineering?

Deep dive into React Fiber


长久以来，在前端工程里我们不断的书写✍️类似的文件头部，引入我们需要的模块，无论是自己编写的组件还是引入公共库。

![image](https://cdn.nanyang.io/images/IMG_0026.PNG)


在之前很长一段时间，这类机制在我看来仿佛[黑箱](https://en.wikipedia.org/wiki/Black_box)一样，对其背后发生感到了好奇

在逐渐理解模块化之后，如果你也对此有过我曾经同样的感受，我想接下来的内容能让你减少一些困惑

## Motivation

我们可能已经习惯书写了各式各样的模块引入方式，但让我们先忘记这些

如果一切还原到最初的时期，仅仅是一些零碎的变量组成的文件

比如 `a.js` 和 `b.js`

![image](https://cdn.nanyang.io/images/IMG_0023.JPG)


那么现在我们需要一点更好玩的东西了，我们需要让 两个文件同时使用公共的第三方变量

> 最好的例子就是 jQuery

![image](https://cdn.nanyang.io/images/IMG_0024.JPG)


可以看到 `a.js` 和 `b.js` 都使用了 jQuery 的变量

那如果我们将 jQuery 删掉，或者改变书写的顺序，比如 `<script>` 放在 引入 `a.js` 或 `b.js`之后

![image](https://cdn.nanyang.io/images/IMG_0025.JPG)

使用 jQuery 的地方将抛出一个错误，并停止继续执行下去

我们这个简单的例子可能有点简陋，不足以说明在类似情景所遇到的困难。维护老代码成了关于作用域的运气游戏或者经历抽丝剥茧才能确定变量被哪些文件引用，才能安全的修改

模块化 提供给我们更好的方式组织变量，拆分/组织不同含义的模块，并且可以明确何时何地引用了哪些变量，显式的关系更容易排查问题，以及可以让引擎去做一些语义分析

## How ES modules work

ES Modules 是 浏览器原生支持的模块系统

而在之前，常用的是 CommonJS 和基于 AMD 的其他模块系统 如 RequireJS

以及 Webpack 自己实现的 模块化系统，在后面我们会再次提及这个

ES Modules 的关键字是 `import` 和 `export`

ES Moudles 模块加载将包含三个主要的阶段，这里简单提要一下

1. `Construction`  —  查找、下载并解析所有文件到模块记录中。
2. `Instantiation`  —  在内存中寻找一块区域来存储所有导出的变量（但还没有填充值）。然后让 export 和 import 都指向这些内存块。这个过程叫做链接（linking）
3. `Evaluation`  —  运行代码，在内存块中填入变量的实际值

这三个阶段可以分开完成，意味着异步的

最后的产物将被称作 `Module Graph` 模块图谱

我们用一个简单的例子来说明`ES Moudles` 加载模块其背后大致发生了什么

## Construction

### Find 查找

通常我们会有一个主文件 `main.js` 作为一切的开始

![image](https://cdn.nanyang.io/images/IMG_0028.PNG)


然后通过 `import` 语句 去 **引入** 其他模块所 **导出** 的内容

![image](https://cdn.nanyang.io/images/IMG_0027.PNG)


`import` 语句中的一部分称为 `Module  Specifier` 。它告诉 `Loader` 在哪里可以找到引入的模块。

![image](https://cdn.nanyang.io/images/IMG_0029.PNG)


注意不同宿主环境下，不同的 `Loader` 实现可能不尽相同，这将导致在 Node 中习惯使用的方式换在浏览器上可能发生错误

比如在 `CommonJS` 中 或者 利用 `Webpack` 进行 `bundled`，我们通常习惯这样书写

```js
import moment from "moment";
```

通过仅仅指定包名称，背后就能通过查询算法找到包的主程序

这个方式的主要优点是可以轻松地在整个生态系统中进行协调。任何人都可以编写一个模块，并使用包的众所周知的包名称，然后让 `Node.js` 运行时 或 其构建时工具 负责将其转换为磁盘上的实际文件

而在浏览器端，目前无法直接这样使用 包名称

> 但在未来或许可以
> 详细请参阅 [import-maps](https://github.com/WICG/import-maps)

在此之前，在 浏览器 只能使用 `URL` 作为 `Module  Specifier` ，也就是使用 `URL` 去加载模块

### Download 下载

而有个问题也随之而来，浏览器在解析文件前并不知道文件依赖哪些模块，当然获取文件之前更无法解析文件，这将导致整个解析依赖关系的流程是阻塞的，

![image](https://cdn.nanyang.io/images/IMG_0030.PNG)


如果浏览器按这样进行解析，那么模块系统会慢到无法使用

而 `CommonJS` 是在 Node 环境下诞生的，从文件系统加载文件比在 Internet 上下载的时间要少得多，这意味着 Node 可以在加载文件时阻塞主线程。而且既然文件已经加载了，直接实例化和求值（在 CommonJS 中并不区分这两个阶段）

所以 `ES Modules` 规范 将 `Construction` 这个步骤单独分离出来，使浏览器在执行同步的初始化过程前可以自行获取并下载文件以及解析

补充：`ES Modules` 规范 没有规定浏览器如何获取（查找/下载）文件，只定义了该如何解析文件（解析文件到 `Module Record`）

这也暗示了 `ES Modules` 可以被称为异步的原因之一

### Parse 解析

刚才已经提及了很多关于解析的内容，实际上解析文件是助于浏览器了解模块内的构成，而我们把它解析出来的模块构成表 称为 `Module Record` 模块记录

![image](https://cdn.nanyang.io/images/IMG_0031.PNG)


模块记录包含了当前模块的 AST，引用了哪些模块的变量，以前一些特定属性和方法

模块记录被创建后将被记录在称作 `Module Map` 的表中

![image](https://cdn.nanyang.io/images/IMG_0032.PNG)


被记录后，如果再有对相同 `URL` 的请求，`Loader` 将直接采用 `Module Map` 中 `URL` 对应的 `Module Record`

当解析完全部文件后，我们将得到很多 `Module Record`

- 另外提及一下不同方式的 Parse 被称为 `Parse Goal` ,使用不同方式 `Parse Goal` 解析相同的 file ，得到的产物也是不一样的，所以我们会在 script 标签 添加 `type = "module"` 来告诉浏览器这个文件将是一个模块

- 但在 Node 中，是没有 HTML 标签的，所以需要其他的方式来辨别，社区目前的主流解决方式是修改文件的后缀为 `.mjs` ，来告诉 Node 这将是一个模块。不过还没有标准化，而且还存在很多兼容问题

在`Construction`过程不会实例化和执行任何的代码，在进行任何求值之前，需要事先构建整个模块图，这也是被称为 **静态解析** 的原因。

正因为此，`Module  Specifier` 也无法使用变量，因为在解析时并没有执行任何代码，也就没有任何状态

而 `CommonJS` 的话，在查找下一个模块之前，执行了此模块中的所有代码（直至 `require` 语句）。这意味着当进行 模块解析 时，变量会有值。

![image](https://cdn.nanyang.io/images/IMG_0034.PNG)


ES Moudle 为了支持在模块路径中使用变量，有一个提案实现它：[动态导入](https://github.com/tc39/proposal-dynamic-import)

![image](https://cdn.nanyang.io/images/IMG_0033.PNG)


原理是 任何通过 `import()` 加载的模块，将称为独立的依赖图入口，也就是说脱离之前的依赖图独自处理（就像 `main.js`）

好了，从普通的主入口文件，到现在我们有了很多 `Module Record`，接下里可以进行 实例化

## Instantiation

为了实例化 `Module Record` ，引擎将采用 `Depth First Post-order Traversal` 深度优先后序进行遍历，JS 引擎将会为每一个 `Module Record` 创建一个 `Module Environment Record` 模块环境记录，它将管理 `Module Record` 对应的变量，并为所有 export 分配内存空间（这个阶段中并未求值）

> 这个阶段中，export 导出的如果是函数，将会被初始化（函数具有提升作用），这有利于下一阶段求值

![image](https://cdn.nanyang.io/images/IMG_0037.PNG)


引擎遍历将深入直到依赖树末端没有任何依赖的文件，处理好每个模块的 export 与 内存连接，之后逐层回溯进行连接该模块的所有 import

请注意，export 和 import 都指向内存中的同一个区域。先连接 export ，保证了所有的 export 都可以被连接到对应的 import 上。

![image](https://cdn.nanyang.io/images/IMG_0035.PNG)


`ES Modules` 的这种连接方式被称为 `Live Bindings` 动态绑定，模块进行 import 将是指向内存中的一块区域。这意味着导出的模块内将可以修改被引用的变量，其修改将会反应在导入该变量的模块中（导入变量的模块无法修改导入的值，如果导入的是对象类型，那么可以修改其属性值）

之所以 `ES Modules` 采用 `Live Bindings`，是因为这将有助于做静态分析（不用执行 Code）以及规避一些问题，如循环依赖。

而 `CommonJS` 导出的是 copy 后的 export 对象，这意味着如果导出模块稍后更改该值，则导入模块并不会看到该更改。

这也就是通常所见到的结论：`CommonJS` 模块导出是值的拷贝，而 `ES Modules` 是值的引用。

## Evaluation

还记得我们 通过内存 连接好了所有 export 和 import 吗，但内存还尚未有值

JS 引擎通过执行顶层代码（函数之外的代码），来向这些内存区添值

![image](https://cdn.nanyang.io/images/IMG_0036.PNG)


和 `Instantiation` 阶段一样，也是通过 深度优先后序 进行遍历，并且通过 `Module Map`，保证模块只会被执行一次

> 也解释了 `ES Modules` 是先执行末端依赖的模块

所以这个阶段可以理解为 执行代码

另外还有个困惑很多人的问题：`ES Modules` 如何处理循环依赖？

其实在 `ES Modules` 下不需要关心是否存在循环依赖，在代码运行的时候，从内存空间中读取该导出值，因为 `ES Modules` 是采用动态绑定的方式

而 `CommonJS` 也有其解决方式

`Node.js` Doc 中关于 [Cycle](https://nodejs.org/api/modules.html#modules_cycles) 有着一句解读

`In order to prevent an infinite loop, an unfinished copy of the a.js exports object is returned to the b.js module.`

若模块被循环依赖，将导出未完成的 Copy 值，也就是导出当前执行完成的导出值

## Webpack Modules

你是否想过为什么在使用 Webpack 打包的前端工程里，并不用多去考虑各个模块加载方式的局限处，反而可以直接使用 `ES Modules` ，甚至混用 `ES Modules` 和 `CommonJS`，在浏览器中运行代码。

其实 Webpack 处理  `ES Modules`/`CommonJS`，是基于自己实现的 `webpack_require`，来抹平各个模块规范的差异。

详细的内容将在另一篇文章里详细阐述

Webpack 如何处理不同的模块加载方式

- Webpack 打包模块
- Webpack 异步加载模块

## Reference

- [ECMAScript Language: Scripts and Modules - Modules](https://tc39.es/ecma262/#sec-modules)
- [MDN - JavaScript modules](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Guide/Modules)
- [ES modules: A cartoon deep-dive](https://hacks.mozilla.org/2018/03/es-modules-a-cartoon-deep-dive)
- [WICG/import-maps](https://github.com/WICG/import-maps)
- [TC39/proposal-import-meta](https://github.com/tc39/proposal-import-meta)
- [TC39/proposal-dynamic-import](https://github.com/tc39/proposal-dynamic-import)

对 ES Modules 的一点理解


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

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

## 设计概念

最常见的应用模式是 **[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)

权限设计的一些思路


## Explanation
[TLA: top-level-await](https://github.com/tc39/proposal-top-level-await) 
这个提案经过两年的”激烈争辩“还是进入到了 stage3。
> 可以在提议链接中了解提议的初因，以及目前进度受到阻碍的细节

之所以能进入这个阶段主要是解决（或者规避）了 [Rich-Harris](https://github.com/Rich-Harris)  提出的初期反对意见 [Top-level await is a footgun](https://gist.github.com/Rich-Harris/0b6f317657f5167663b493c722647221)

Harris 最新的更新也写明了[他完全支持目前提案的新方向](https://gist.github.com/Rich-Harris/0b6f317657f5167663b493c722647221#edit--february-2019)

**简单讲 TLA 的新方向解决了3个主要的问题**: 

1. 具有 TLA 的模块不会阻止同级执行，也就是同级不会阻碍
1. 只支持 ES-Module，规避了 CJS 或普通 script 会出现的问题
1. 不会阻碍资源加载，因为 TLA 在模块的执行阶段，此时已完成加载

另外 之前没有 TLA，比较 hack 的代替方法是 `(async main(){...}())` ，不会有阻塞问题，但会对静态分析造成困难

目前 TLA 还有一些[问题](https://github.com/tc39/proposal-top-level-await#does-top-level-await-increase-the-risk-of-deadlocks)待解决


## References
1. https://github.com/tc39/proposal-top-level-await
1. https://v8.dev/features/top-level-await


TLA isn't a footgun anymore


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



## Description
The Permissions API allows a web application to be aware of the status of a given permission, to know whether it is granted, denied or if the user will be asked whether the permission should be granted.

## Permissions.query() 
查询给定API的权限状态，返回状态，可以实时监听状态的变更。

我们可以利用它获取权限的状态，以及状态变更获得通知

### State Type

1. `granted`
2. `denied`
3. `prompt`

弹出的 `权限询问框` 有三种情况处理：

1. 点击`允许`：会返回状态变更为 `granted`
2. 点击`禁止`：会返回状态变更为 `denied`
3. 点击 `关闭按钮`：只有 `Notification API` 特殊实现，会返回自身实现的一种状态，为：`default`

例子：
```js
 navigator.permissions.query({
    name: 'microphone'
}).then(p => {
    console.log('microphone', p.state);
	  // onchange 监听 状态变更
    p.onchange = function () {
        console.log('microphone', this.state);
    };
});
```


## 关于 Requesting Permissions
也就是用户点击 允许、禁用、关闭 之后的回调

某些权限具有的API可以特殊实现 关闭 的回调

### Notification

 [Notification API](https://notifications.spec.whatwg.org/#permission)

例如 `通知的 Notification.requestPermission`
```js
Notification.requestPermission(function(result) {  
  if (result === 'denied') {  
    console.log('Permission wasn\'t granted. Allow a retry.');  
    return;  
  } else if (result === 'default') {  
    console.log('The permission request was dismissed.');  
    return;  
  }  
  console.log('Permission was granted for notifications');  
});
```

> 备注：3 次 `点击关闭` 权限询问框，Chrome 自动导致状态变更：`prompt` ——> `denied`，需要手动将权限置为其他状态


### Navigator.getUserMedia
[MediaDevices.getUserMedia() | MDN](https://developer.mozilla.org/zh-CN/docs/Web/API/MediaDevices/getUserMedia)

关于 获取 麦克风、摄像头 权限，也有一套自己的实现
利用 `navigator.getUserMedia` 三种状态都能获取

```js
// 旧API
navigator.getUserMedia({
    audio: true,
    video: true
}, function (stream) {
    preview.src = window.URL.createObjectURL(stream);
    preview.play();

    recordVideo = RecordRTC(stream, {
        type: 'video'
    });

    recordVideo.startRecording();

    stop.disabled = false;
}, function (error) {
    alert(error.toString());
});

// 新API
navigator.mediaDevices.getUserMedia({
    audio: true
}).then((stream) => {
    return stream;
}).catch(err => console.log(err.message))

// catch 的参数 是 DOMException 包装对象，在 web API中如何描述错误情况的对象

```


## 总结
### 1. 查看当前权限状态：
#### API: 

`navigator.permissions.query`

首先, 一个权限的状态分为三种: 

1. granted (授予)
1. denied  (拒绝)
1. prompt  (询问)

> 后两种都是未获得用户授权的状态。


denied 状态包含 用户拒绝授权、无设备

### 2. 询问用户，获取授权权限：
#### API: 
`navigator.mediaDevices.getUserMedia`

获取用户授权，会导致弹出询问框；如果没有设备，将不会弹出询问框

用户点击 授权询问框 的情况有三种

1. 允许
2. 禁止
3. 关闭弹框

> 若没有设备，将直接返回 没有设备 的状态

**用户在发生三种行为的回调，技术层面都可以获得**

> 只有在 prompt 状态 ，询问框才会弹出

用户的 未授权 和 没有录音设备状态，在第二种是可以区分的



## Reference
- [Permissions API Sample](https://googlechrome.github.io/samples/permissions/)
- <del>[navigator.getUserMedia | MDN](https://developer.mozilla.org/zh-CN/docs/Web/API/Navigator/getUserMedia)</del>
- [RecordRTC Simple Demos](https://www.webrtc-experiment.com/RecordRTC/simple-demos/)
- [MediaDevices.getUserMedia() | MDN](https://developer.mozilla.org/zh-CN/docs/Web/API/MediaDevices/getUserMedia)
- [WebRTC API | MDN](https://developer.mozilla.org/zh-CN/docs/Web/API/WebRTC_API)
- [DOMException | MDN](https://developer.mozilla.org/zh-CN/docs/Web/API/DOMException)


Permissions API 踩坑


## 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;
    }
}
```

### 这段 code 的要点是：

1. memoize 函数的 返回值是一个 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)

介绍 Memoization

> 某天和同事们讨论了一下经常逛的技术blog网站，列举了一下，eg.: medium、Reddit、Hacker News、SF、

其中说到了 `medium` 的前端技术很不错，页面做了很多优化点，其中一点就是 加载图片 的时候，图片会有一段高斯模糊的过程，由于用户可以提前感知到图片的大致内容，使得网页加载整个体验非常顺滑。

> 具体流程，可以随便打开medium的帖子感受下（如果想详细看到整个过程。devTools 禁用缓存并限制网速）


# 开始

其实有关这部分的 DOM 结构很简单，简化后如下：

```html
<figure>
  <div>
    <div/> 
    <img/> 
    <canvas/> 
    <img/> 
    <noscript/> 
  </div>
</figure>
```


下面是实际的例子：
```html
<figure name="7012" id="7012" class="graf--figure graf--layoutFillWidth graf-after--h4">
  <div class="aspectRatioPlaceholder is-locked">
    <div class="aspect-ratio-fill" style="padding-bottom: 66.7%;"></div>
    <div class="progressiveMedia js-progressiveMedia graf-image is-canvasLoaded is-imageLoaded" data-image-id="1*sg-uLNm73whmdOgKlrQdZA.jpeg" data-width="2000" data-height="1333" data-scroll="native">
      <img src="https://cdn-images-1.medium.com/freeze/max/27/1*sg-uLNm73whmdOgKlrQdZA.jpeg?q=20" crossorigin="anonymous" class="progressiveMedia-thumbnail js-progressiveMedia-thumbnail">
        <canvas class="progressiveMedia-canvas js-progressiveMedia-canvas" width="75" height="47"></canvas>
        <img class="progressiveMedia-image js-progressiveMedia-image __web-inspector-hide-shortcut__" data-src="https://cdn-images-1.medium.com/max/1800/1*sg-uLNm73whmdOgKlrQdZA.jpeg" src="https://cdn-images-1.medium.com/max/1800/1*sg-uLNm73whmdOgKlrQdZA.jpeg">
        <noscript class="js-progressiveMedia-inner">&lt;img class="progressiveMedia-noscript js-progressiveMedia-inner" src="https://cdn-images-1.medium.com/max/1800/1*sg-uLNm73whmdOgKlrQdZA.jpeg"&gt;</noscript>
    </div>
  </div>
</figure>
```
> 图像大小取决于设备。


## 发生了什么？

1. 首先，加载小尺寸的图片
2. 在 小尺寸的图片 在 loaded 完成后，将其应用在 canvas 上，并设置 blur 值
3. 第二步骤的同时加载大尺寸图片，加载完成后，插入DOM中，设置 z-index 值覆盖掉 canvas ，并将 canvas 设置 `visibility: hidden;  opacity: 0;` 
4. 整个过程流畅，应用了 CSS transition 

> 由于每个子元素都是相互覆盖关系，使用了定位属性，在图片加载成功之前，会引发 高度collapse ，所以采用一个占位符来撑开高度：主要利用了 padding-bottom，根据宽度来设置高度

获取加载成功的状态
```js
  const img = new Image();
  img.src = small.src;
  img.onload = function () {
   small.classList.add('loaded');
  };
```

大致过程就是这样，具体实现就不详细说了

思考优化图片加载


在 React v16.7.0 alpha 版本里，提出了一个新的 Feature Proposal ：Hooks ，对社区以及以后前端发展所带来的影响是巨大的。

> 学习 Hooks 的知识需要对 React 生态有较深入的理解

# What is the Hooks ？
Hooks 是 React 内部组件中的一系列特殊函数，直观带来的改变是引入state、生命周期函数、或者其他 React 功能，无需使用 classes 编写组件（类语法带来的问题有很多），背后为前端带来更深入更普及的 `functional programming` 思想。

## 引入 Hooks 的动机 
React 官方阐明了引入 Hooks 的动机，Hooks 出现前，我们编写 React 组件 会经常遇到的问题：

1. `It’s hard to reuse stateful logic between components`
	- React 没有提供官方方案去解决 `组件之间共享复用有状态逻辑` ，组件间逻辑的复用和数据传递就变得十分困难（必须一层一层往下传），所以我们使用  `render props` 和 `higher-order components` 来解决复用逻辑的同时引来了新的问题，一些无关 UI 的 wrapper 组件越来越多，嵌套组件越来越深，形成 `wrapper hell` ，虽然 [React devTools](https://github.com/facebook/react-devtools/pull/503) 有过滤器来帮助我们更容易地调试。
	- **使用 Hooks 可以在不改变组件层次结构的情况下复用有状态逻辑**。可以利用 custom hooks，复用包含状态的逻辑，这些逻辑不再出现在组件树中，而是形成一个独立、可测试的单元，但仍然响应 React 在渲染之间的变化；社区之间分享 自定义hooks 更容易，hooks 就像插件一样。
2. `Complex components become hard to understand`
	- 随着项目深入，我们逐渐会编写越来越复杂的逻辑在组件中，这导致了再生命周期函数内编写的逻辑非常臃肿，例如 `添加监听器`，我们需要在`componentDidMount` 与 `componentWillUnmount` 中分别编写添加与删除监听器的逻辑，而一般在 `componentDidMount` 中，我们也会编写 `请求数据` 的逻辑。各种功能不相关联的逻辑写在一起，而且相同功能的逻辑散落在不同函数内，这带来许多隐患以及调试上的困难
	- **使用 Hooks 可以 将相关联的逻辑code由组件拆分出来成更简单直观的函数（例如订阅事件、请求数据）**
3. `Classes confuse both people and machines`
	- React 官方认为 JS 的 Class 语法的学习成本很高，使用类语法，要必须清楚 `this` 在 JS 的工作方式，例如我们需要 绑定事件处理程序 （以何种方式绑定这里不是重点，个人推荐箭头函数形式）；另外一些重要实践上，使用 Class 语法也带来诸多问题，详细参阅 [classes-confuse-both-people-and-machines](https://reactjs.org/docs/hooks-intro.html#classes-confuse-both-people-and-machines))
	- 使用 Hooks 可以 在无需编写 Class 语法的情况下 引入state、生命周期函数、或者其他 React 功能

## 实际上引入 Hooks 并不会给现有的代码带来问题

1. 完全可选（将使用 Hooks 的选择权交给开发者）
2. 向后兼容（不会有任何破坏性更改）
3. 在可预见的未来内，不会从 React 中删除 类语法
4. Hooks 并没有颠覆之前的 React 概念。相反，带来更直观的 API 实现相同的功能

# 编写 Hooks
目前主要的 Hooks ：

1. State hooks 
2. Effect hooks 
3. Custom hooks （自定义 hooks 用来复用包含状态的逻辑）

## useState

```js
import { useState } from 'react';

function Example() {
  // Declare a new state variable, which we'll call "count"
  const [count, setCount] = useState(0);

  return (
    <div>
      <p>You clicked {count} times</p>
      <button onClick={() => setCount(count + 1)}>
        Click me
      </button>
    </div>
  );
}
```

使用 `state hooks` 在 `function components`中可以像上面代码这样，等同于Class语法的代码就不贴了。

> 值得一提的是，在 Hooks 出现之前，我们通常叫这样形式的组件为 `stateless components` or `stateless function components` ，但现在，有了 Hooks ，我们可以在这类组件中使用 state，所以改称 `function components`。

1. useState 的参数是 我们需要定义的 state 名的初始值（不必像以前一样，state 必须为 Object，如果我们想要创建两个state，就调用两次 useState）
2. 返回值是包含两个值的数组，两个值分别为 `当前状态` 和 `更新它的函数` 。（这里我们使用 `array destructuring` 的方式将值取出来。）


创建多个 state 就像这样
```js
function ExampleWithManyStates() {
  // Declare multiple state variables!
  const [age, setAge] = useState(42);
  const [fruit, setFruit] = useState('banana');
  const [todos, setTodos] = useState([{ text: 'Learn Hooks' }]);
```

与 `this.setState` 不同，更新状态总是替换它而不是合并它（也解决了很多之前合并带来的问题）

### Functional updates

如果新的 state 值是依赖上一个 state 值来计算的，我们可以给 `setState` 传递一个函数参数，这个函数的参数为上一个 state 的值，返回值是更新后的 state 值，例如：
```js
function Counter({initialCount}) {
  const [count, setCount] = useState(initialCount);
  return (
    <>
      Count: {count}
      <button onClick={() => setCount(0)}>Reset</button>
      <button onClick={() => setCount(prevCount => prevCount + 1)}>+</button>
      <button onClick={() => setCount(prevCount => prevCount - 1)}>-</button>
    </>
  );
}
```

所以如果需要更新的 state 值为 Object，我们应该使用 `object spread syntax`
```js
setState(prevState => {
  // Object.assign would also work
  return {...prevState, ...updatedValues};
});
```

### 延迟初始化 state
如果初始化的值是需要大量计算得到的结果，可以使用函数代替，此函数只会在初始化阶段执行
```js
const [state, setState] = useState(() => {
  const initialState = someExpensiveComputation(props);
  return initialState;
});
```

## useEffect

Effect 其实就是 请求数据，操作DOM，以及订阅事件等一系列 副作用/效果

而 useEffect 则是 之前 `componentDidMount`，`componentDidUpdate` 和`componentWillUnmount` 的结合

React组件中有两种常见的 Effect：需要清理和不需要清理的 Effect

### 不需要清理的 Effect
```js
import { useState, useEffect } from 'react';

function Example() {
  const [count, setCount] = useState(0);

  useEffect(() => {
    document.title = `You clicked ${count} times`;
  });

  return (
    <div>
      <p>You clicked {count} times</p>
      <button onClick={() => setCount(count + 1)}>
        Click me
      </button>
    </div>
  );
}
```

1. 将在每次渲染后执行 useEffect 
2. useEffect 写在 函数内部是为了直接访问到state值，利用了闭包的性质，不需要额外 API

### 需要清理的 Effect

```js
import { useState, useEffect } from 'react';

function FriendStatus(props) {
  const [isOnline, setIsOnline] = useState(null);

  function handleStatusChange(status) {
    setIsOnline(status.isOnline);
  }

  useEffect(() => {
    ChatAPI.subscribeToFriendStatus(props.friend.id, handleStatusChange);
    // Specify how to clean up after this effect:
    return function cleanup() {
      ChatAPI.unsubscribeFromFriendStatus(props.friend.id, handleStatusChange);
    };
  });

  if (isOnline === null) {
    return 'Loading...';
  }
  return isOnline ? 'Online' : 'Offline';
}
```

需要单独的 API 来执行清理逻辑。因为添加和删除订阅的逻辑是相关的，useEffect 旨在将其保持在一起。
如果 useEffect 返回一个函数，React 将在清理时执行它

> 清理的时机是 `当组件卸载时`，但，useEffect 会在每次渲染后运行而不仅仅是一次， 这就是 React 在下次执行 useEffect 之前还清除前一个 useEffect 的原因；[Using the Effect Hook – React](https://reactjs.org/docs/hooks-effect.html#explanation-why-effects-run-on-each-update)

如果要减少 useEffect 内并不是每次渲染都必要的逻辑，可以：

```js
useEffect(() => {
  document.title = `You clicked ${count} times`;
}, [count]); // Only re-run the effect if count changes
```

React 会比较两次渲染的 count 值，如果一样，就会跳过这次 useEffect

## Custom Hooks

我们可以封装在多个组件可重用的包含状态的逻辑，例如

```js
import { useState, useEffect } from 'react';

function useFriendStatus(friendID) {
  const [isOnline, setIsOnline] = useState(null);

  function handleStatusChange(status) {
    setIsOnline(status.isOnline);
  }

  useEffect(() => {
    ChatAPI.subscribeToFriendStatus(friendID, handleStatusChange);
    return () => {
      ChatAPI.unsubscribeFromFriendStatus(friendID, handleStatusChange);
    };
  });

  return isOnline;
}
```

`useFriendStatus` 就是一个我们写好的复用逻辑函数，供其他组件调用。

> **多个组件使用 相同自定义Hooks，它们的状态和效果是 独立隔离的**，仅仅是逻辑的复用。因为本质是 `调用 Custom Hooks` 是调用 `useState` 和 `useEffect`，它们在一个组件调用很多次，彼此产生的状态也是完全独立的。

详细参见文档：[Writing Custom Hooks – React](https://reactjs.org/docs/hooks-custom.html)


## 使用 Hooks 的规则：
务必遵守的规则：
[Rules of Hooks – React](https://reactjs.org/docs/hooks-rules.html)

Hooks API：
[Hooks API Reference – React](https://reactjs.org/docs/hooks-reference.html)


# Conclusion
React Hooks 带来的边际效应可以说是巨大的，希望更加完善之后，可以看到打开新窗的前端。

启发 Hooks 的产生：[Hooks FAQ – React](https://reactjs.org/docs/hooks-faq.html#what-is-the-prior-art-for-hooks)

关于 Hooks 的讨论：[RFC: React Hooks by sebmarkbage · Pull Request #68 · reactjs/rfcs · GitHub](https://github.com/reactjs/rfcs/pull/68)

> 有趣的是，Vue的作者也很快创建了在 Vue 实验 Hooks 的repo：[GitHub - yyx990803/vue-hooks: Experimental React hooks implementation in Vue](https://github.com/yyx990803/vue-hooks)

> Dan 写了一篇讲解文章： [Making Sense of React Hooks](https://medium.com/@dan_abramov/making-sense-of-react-hooks-fdbde8803889) 



React Hooks (Proposal)


![img](https://cdn-images-1.medium.com/max/1600/1*dNtmhr-N1J1L__E2rEj5jg.png)


# the good part
简洁！async/await 给我们带来的最重要的好处是同步编程风格，也只是风格而已，它是Promise的语法糖。

**任何async函数都会隐式返回一个promise，而promise的解析值将是return的值**

意味着：
1. Returning a non-Promise value fulfills p with that value.
2. Returning a Promise means that p now mirrors the state of that Promise.


```js
// async
async getBooksByAuthorWithAwait(authorId) {
  const books = await bookModel.fetchAll();
  return books.filter(b => b.authorId === authorId);
}

// promise
getBooksByAuthorWithPromise(authorId) {
  return bookModel.fetchAll()
    .then(books => books.filter(b => b.authorId === authorId));
}
```

async 改变了常规的异步调用写法





# the bad part

## 异步等待
初次接触可能会带来误区，虽然await可以使代码看起来像同步，但事实上仍为异步。

**await关键字，这将告诉JavaScript不立即执行下一行，而是等待promise返回解析值之后执行下一行**
通常 await 命令后面是一个 Promise 对象（大多数情况是我们发起请求之后返回的promise）。如果不是，会被转成一个立即resolve的 Promise 对象。


```js
async getBooksAndAuthor（authorId）{ 
  const books = await bookModel.fetchAll(); 	// 1
  const author = await authorModel.fetch(authorId);	// 2 

  return { 
    author，
    books：books.filter(book => book.authorId === authorId)，
  }; 
}
```


第二行代码 会直到 bookModel.fetchAll() 返回之后才会执行

但其实 authorModel.fetch(authorId) 不依赖于bookModel.fetchAll()的结果，所以实际上它们可以并行调用！但是，通过await在这里使用，这两个调用变为“同步”顺序，并且总执行时间将比并行版本长得多。

所以改进之后的版本：

```js
async getBooksAndAuthor（authorId）{ 
  const bookPromise = bookModel.fetchAll（）; 
  const authorPromise = authorModel.fetch（authorId）; 

  const book = await bookPromise; 
  const author = await authorPromise; 

  return { 
    author，
    books：books.filter（book => book.authorId === authorId），
  }; 
}
```

异步函数（bookModel.fetchAll() 和  authorModel.fetch(authorId)）将返回一个promise，可以在以后使用它，并且bookPromise 和 authorPromise 将并行调用。
**所以多个await命令后面的异步操作，如果不存在继发关系，最好让它们同时触发**。

这里是利用到了 promise 的特性，**你可以在一行中得到一个 promise 并等待它在另一行中resolve 或 reject**

至于之后为什么要 await bookPromise 和 await authorPromise，是因为编译器不会知道我们要等待函数完成执行。因此，编译器将退出程序而不完成异步任务。所以我们需要 await 关键字。




> 当然这其实不属于 async 不好的部分，相反，如果你的需求是调用第二行代码是依赖于第一行代码的返回值，使用 async 可就比使用 promise 简单清晰的多（你懂得，promise会写出多层 .then 嵌套）。





## 错误处理
只要一个await语句后面的 Promise 变为reject，那么整个async函数都会中断执行。
```js
async function f() {
  await Promise.reject('出错了');
  await Promise.resolve('hello world'); // 不会执行
}
```
上面代码中，第二个await语句是不会执行的，因为第一个await语句状态变成了reject。

有时，我们希望即使前一个异步操作失败，也不要中断后面的异步操作。
这时可以将第一个await放在try...catch结构里面，这样不管这个异步操作是否成功，第二个await都会执行。
```js
async function f() {
  try {
    await Promise.reject('出错了');
  } catch(e) {
  }
  return await Promise.resolve('hello world');
}

f()
.then(v => console.log(v))
// hello world
```
另一种方法是await后面的 Promise 对象再跟一个catch方法，处理前面可能出现的错误。
```js
async function f() {
  await Promise.reject('出错了')
    .catch(e => console.log(e));
  return await Promise.resolve('hello world');
}

f()
.then(v => console.log(v))
// 出错了
// hello world
```

async&await 两面性


![img](https://camo.githubusercontent.com/71cab2efcf6fb8401a2f0ef49443dd94bffc1373/68747470733a2f2f757365722d676f6c642d63646e2e786974752e696f2f323031382f332f31332f313632316538613962636230383732643f773d34383826683d35393026663d706e6726733d313531373232)

## 第一种
**Object.__proto__ === Function.prototype**
看完上面一个很常见的 原型链 图示，看下面的例子：

```js
let obj = {};
obj.__proto__ === Object.prototype;    //	return true
```
OK，结果显而易见是没有问题的；声明一个对象，对象的隐式原型 [[Prototype]]（内部属性，我们并不能访问到，所以使用 `__proto__` 来访问）与它的构造函数的原型连接起来。

那么看下个例子：
```js
Object.__proto__ === Object.prototype; 	//	return false
```

可能会觉得有些诧异，为什么Object的原型链指向了自己的原型？？

其实这里的Object是构造函数；也就是说，它是一个函数，而不是一个纯对象。（这里说的对象是数据类型）
那么一个函数的原型链首先就会指向 `Function.prototype`了。

**规范是这么写的**：
> The value of the [[Prototype]] internal property of the Object constructor is the standard built-in Function prototype object.
> 
> The value of the [[Prototype]] internal property of the Object prototype object is null, the value of the [[Class]] internal property is "Object", and the initial value of the [[Extensible]] internal property is true.

所以：
```js
Object.__proto__ === Function.prototype;		// return true
```


## 第二种
**Function.__proto__ === Function.prototype**

让我们先来看下这个例子的结果：
```js
Function.__proto__ === Function.prototype	// return true
```

会不会有些疑惑？
Function 的`__proto__`指向了它本身的原型 ？？因为我们普遍的认知就是：实例对象的`__proto__`属性指向它的构造函数的原型对象(prototype)。

规范这样说：

**Function.prototype是个不同于一般函数（对象）的函数（对象）**。

> 1. The Function prototype object is itself a Function object (its [[Class]] is "Function") that, when invoked, accepts any arguments and returns undefined.
> 
> 2. The value of the [[Prototype]] internal property of the Function prototype object is the standard built-in Object prototype object (15.2.4). The initial value of the [[Extensible]] internal property of the Function prototype object is true.
> 
> 3. The Function prototype object does not have a valueOf property of its own; however, it inherits the valueOf property from the Object prototype Object.

### 解释

1. `Function.prototype` 像普通函数一样可以调用，但总是返回 `undefined`。
2. 普通函数实际上是`Function`的实例，即普通函数继承于`Function.prototype`。例如：`func.__proto__ === Function.prototype`。
3. `Function.prototype` 继承于 `Object.prototype`，并且没有`prototype`这个属性（函数都有prototype属性，除了`Function.prototype`）。`func.prototype` 是普通对象，`Function.prototype.prototype` 是 `null`。

所以，`Function.prototype` 其实是个另类的函数，可以独立于/先于 `Function` 产生。


回归到上面的疑惑，为什么 `Function.prototype`  和 `Function.__proto__` 是同一个对象？

1. 首先，`Function` 本身是一个函数
2. `Function.prototype` 是所有 `function` 的原型（包括`Function`自己）。 

### 所以疑惑可以这样解释：

`Function.prototype` 和 `Function.__proto__` 相同不代表`Function`这个函数是由自身创建的。先有了Function.prototype这个函数对象，然后才有了 function Function() 而已。然后其他的构造函数都是 function Function() 生成的。


## Conclusion
- **先有 Object.prototype（原型链顶端），Function.prototype 继承 Object.prototype 而产生，最后，Function 和 Object 和其它构造函数继承 Function.prototype 而产生**。

- 每个函数都有 `prototype` 属性，除了 `Function.prototype`



> 不足&疑惑之处，欢迎讨论

原型链深入


> 关于【属性初始化】概念可以参阅 #75 & [proposal-class-fields](https://github.com/tc39/proposal-class-fields)

起因是在我了解 `属性初始化` 概念后，实在太喜欢这样简洁的 cool syntax，看了很多相关的文章和官方概念，发现一个有趣的地方。

**Class的`属性初始化语法`结合`箭头函数`** 与  **Class标准的类方法** 在 babel6 编译成 ES5 的实现方式其实是不同的

### Standard es6 class method
```js
import React, {Component} from 'react';

export default class MethLab extends Component {
    
    constructor(props) {
        super(props);
        
        this.state = {
            methQuality: 'blueSky'
        };
        
        // 手动绑定 printQuality 函数的上下文context在 MethLab 的实例上

        this.printQuality = ::this.printQuality;
    }
    
    // 使用标准的 ES6 类的方法
    printQuality() {
        console.log(`${this.state.methQuality}`);
    }
}
```
### Property initializer with arrow function
```js
import React, {Component} from 'react';

export default class MethLab extends Component {
    
    constructor(props) {
        super(props);
        
        this.state = {
           methQuality: 'blueSky'
        };
    }
    
    // 使用 属性初始化语法结合箭头函数绑定this
    printQuality = () => {
        console.log(`${this.state.methQuality}`);
    };
}
```

两者达成的实际效果是一致的，并且后者优点是不用手动绑定this，非常简洁。

但经过 babel6 编译之后是这样的：

### Standard es6 class method in es5
```js
function MethLab(props) {
    ...

    // manually bind "this" context of printQuality function
    // to the instance of MethLab being constructed
    this.printQuality = this.printQuality.bind(this);
    
    ...
}

MethLab.prototype.printQuality = function printQuality() {
    console.log(this.state.methQuality);
};
```

### Property initializer with arrow function in es5
```js
function MethLab(props) {
    ... 
    
    this.printQuality = function () {
        console.log(this.state.methQuality);
    };

    ...
}
```

很明显，标准的ES6类的方法经过编译之后，类的方法转为函数原型上的函数；而箭头函数转换为构造函数中的方法。

这意味着，在构造函数中声明的实例属性，这些属性特定于实例，不在多个实例中共享，每次为创建实例都会创建相同效用的函数，效率不高。而函数原型上声明共享的属性。将在所有实例中共享，节省性能。

由于两者在性能原因上的差异，如果对性能要求非常苛刻，建议还是采用 ES6标准类方法的语法（但我还是更多的使用属性初始化结合箭头函数这种简洁的语法）

本文的重点在于讨论两种语法进行 babel 转换为 ES5 背后实现的异同

### 其实 ES6 Class 的话：

1. `Class properties`：类方法声明的函数将会在原型上声明，实例中是没有的
1. `Class properties + constructor bind`：如果类方法在 constructor 中进行了 bind ，那么在实例中也会声明函数，因为 constructor 是初始化实例时调用
1. `Public Class Fields + Arrow Function`：只会在实例上声明
