![crypto.com pay logo](https://cdn.nanyang.io/images/crypto-pay-logo.png)

# Background

Before we dive into the technical details, let's take a look at the background of the project.

This post comes from a technical doc I shared within the Crypto.com, after data desensitization and security checks to write down with some thoughts.

**[Crypto.com](https://www.crypto.com)** is a payment, cryptocurrency and NFT platform that empowers users to buy, sell, and pay with crypto.

**Crypto.com** **Pay** offers an ever-expanding set of cryptocurrency payments methods such as Crypto.com App, MetaMask, WalletConnect protocol wallet, like DeFi Wallet/ImToken/Ledger and more.

Here is an e-commerce site that shows the payment flow of Crypto.com Pay where you can select an item to add to your cart and checkout using Crypto.com Pay: [shop.crypto.com](https://shop.crypto.com)

This is an example of my shopping cart:

<figure>
  <img
  src="https://cdn.nanyang.io/images/checkout.png"
  alt="crypto.com pay checkout">
  
</figure>

after click checkout button, you can see the popup window of payment flow:

<figure>
  <img
  src="https://cdn.nanyang.io/images/payment-flow-1.png"
  alt="payment flow">
  
</figure>

The following is a list of common payment scenarios:

<table>
  <tr>
     <td>Crypto.com App</td>
     <td>MetaMask/WalletConnect</td>
     <td>Other Cryptocurrency Wallet</td>
  </tr>
  <tr>
    <td><img src="https://cdn.nanyang.io/images/crypto.com-app.png" width=270 height=250></td>
    <td><img src="https://cdn.nanyang.io/images/metamask.png" width=370 height=260></td>
    <td><img src="https://cdn.nanyang.io/images/transfer.png" width=370 height=260></td>
  </tr>
 </table>

Users can pay by scanning the QR code using the supported wallet app or by using the web3 wallet, during this process we need some realtime feedback to be presented on the page, such as onchain information and transaction data from the database.
However, our current (were) technical implementation does not ensure data on time, which compromises user experience we delivery and increases our server-side maintenance costs.

We strive to balance this time pressure and inclination toward duplication with maintaining our standards of high-quality code.

At Crypto.com, engineering excellence is a high business priority. We regularly invest in refactoring and reducing tech debt. However, we rarely allot time to rewrite projects completely. Instead, we bake refactoring, re-evaluating, and optimizing our software designs into meeting product objectives.

As we developed more and more features about payment flow, we generalized our implementation for the sake of future payment methods. We leveraged our past design decisions to carve out time in our roadmap. This additional time allowed us to optimize for future integrations reducing development time and complexity. This kind of thoughtful re-evaluation is critical in long-lived code-bases.

So after discussions and collaboration between our internal technical teammates and product managers, we decided to design a solution and refactor our features about data on time.

# Implementation

**Here is a step-by-step path for our thinking and implementation**

Our web apps (Payment SDK, **, **) needed some realtime data and our client currently asking server for updates at certain regular intervals, there are a few pitfalls we found with this approach.

- Long/short polling (client pull)

  > HTTP Polling: Periodically check for data. For instance, you could get a response from the server for data every two seconds. But every request to the client costs someone something.

- Multiplexing (Polling responses can’t really be in sync)
- Polling requiring 3 round-trips (TCP SIN, SSL, and Data)
- Timeouts (Connection getting closed by the proxy server if it remains idle for too long)

<br>

We decided to refactor the technical implementation in this case, using server push technology to achieve a good experience and reduce the consumption of resources

> Server push — server is proactively pushing updates to the client (reverse of client pull)

- WebSockets (server push)

## WebSockets

- A WebSocket is a persistent two-way TCP connection (full-duplex) between the server and the client
- The server can push an event without having to receive a request from the client
- A handshake initiates the WebSocket connection really a [TCP connection](http://www.taltech.com/datacollection/articles/a_brief_overview_of_tcp_ip_communications)

### Why not SSE (Server-Sent Events)

> [Server-Sent Events (SSE)](https://ably.com/server-sent-eventsis) based on something called Server-Sent DOM Events, which was first implemented in Opera 9. The idea is simple: a browser can subscribe to a stream of events generated by a server, receiving updates whenever a new event occurs. This led to the birth of the popular EventSource interface, which accepts an HTTP stream connection and keeps the connection open while retrieving available data from it.
> The connection is kept open (until it receives an instruction to be closed) by calling [EventSource.close()](https://developer.mozilla.org/en-US/docs/Web/API/EventSource/close). SSE is a standard describing how servers can initiate data transmission towards clients once an initial client connection has been established. It provides a memory-efficient implementation of XHR streaming. Unlike a raw XHR connection, which buffers the full received response until the connection is dropped, an SSE connection can discard processed messages without accumulating all of them in memory. SSE is designed to use the JavaScript EventSource API to subscribe to a stream of data in any popular browser. Through this interface, a client requests a particular URL to receive an event stream. SSE is commonly used to send message updates or continuous data streams to a browser client. In summary, a server-sent event is when updates are pushed (rather than pulled, or requested) from a server to a browser.

## Weighing up the two

### A. WebSockets

- Advantages (additional)
  - WebSockets generally do not use 'XMLHttpRequest', and as such, headers are not sent every-time we need to get more information from the server. This, in turn, reduces the expensive data loads being sent to the server.
  - WebSockets can transmit both binary data and UTF-8
  - https://caniuse.com/#search=websocket of all browsers in 2020
- Potential stumbling blocs
  - When connections are terminated WebSockets don’t automatically recover – this is something you need to implement yourself, and is part of the reason why there are many https://ably.com/download in existence.
  - Note that browsers older than 2011 don't support WebSocket connections.

### B. SSE

- Advantages
  - Transported over simple HTTP instead of a custom protocol
  - Can be poly-filled with javascript to"backport"SSE to browsers that do not support it yet.
  - Built-in support for re-connection and event-id
  - Useful for apps that enable one-way communication of data, eg live stock prices
- Potential stumbling blocks
  - SSE is limited to UTF-8, and does not support binary data.
  - SSE is subject to limitation with regards to the maximum number of open connections. This can be especially painful when opening various tabs as the limit is per browser and set to a very low number (6).
  - SSE is mono-directional

## Which is better?

This is largely a question of technical debt, which, rather than being categorically a 'bad thing', can sometimes be leveraged and/ or save time in the short term.

WebSockets are undoubtedly more complex and demanding than SSEs, and require a bit of developer input up front. For this investment, we gain a full-duplex TCP connection that is useful for a wider range of application scenarios.

SSE is a simpler and faster solution, but it isn't extensible: if our web apps requirements were to change, the likelihood is it would eventually need to be refactored using. And SSE gets a limited amount of connections.
Although WebSocket technology presents more upfront work, it's a more versatile and extensible framework.



Dive more into the details of the implementation and how we are going to tackle this.

## Socket.IO vs Plain WebSockets

> What [Socket.IO](http://Socket.IO) is
>
> Socket.IO is a library that you can consider the Socket.IO client as a "slight" wrapper around the WebSocket API
>
> The Socket.IO codebase is split into two distinct layers:
>
> 1. the low-level plumbing: what we call [Engine.IO](http://Engine.IO), the engine inside [Socket.IO](http://Socket.IO)
> 2. the high-level API: Socket.IO itself

Although [Socket.IO](http://Socket.IO) indeed uses WebSocket as a transport when possible, it adds additional metadata to each packet. That is why a WebSocket client will not be able to successfully connect to a [Socket.IO](http://Socket.IO) server, and a [Socket.IO](http://Socket.IO) client will not be able to connect to a plain WebSocket server either.

### Benefit of Socket.IO

Here are the features provided by [Socket.IO](http://Socket.IO) over plain WebSockets:

- reliability (fallback to HTTP long-polling in case the WebSocket connection cannot be established)
- automatic reconnection
- [packet buffering](https://socket.io/docs/v4/client-offline-behavior/#buffered-events)
- [acknowledgments](https://socket.io/docs/v4/emitting-events/#acknowledgements)
- [broadcasting to all clients](https://socket.io/docs/v4/broadcasting-events/) or [to a subset of clients](https://socket.io/docs/v4/rooms/) (what we call "Room")
- [multiplexing](https://socket.io/docs/v4/namespaces/) (what we call "Namespace")

### And anther point: Upgrade Mechanism

By default, the Socket.IO client establishes the connection with the HTTP long-polling transport.
While WebSocket is clearly the best way to establish a bidirectional communication, experience has shown that it is not always possible to establish a WebSocket connection, due to corporate proxies, personal firewall, antivirus software...
From the user perspective, an unsuccessful WebSocket connection can translate in up to at least 10 seconds of waiting for the realtime application to begin exchanging data. This perceptively hurts user experience.
To summarize, Socket.IO focuses on reliability and user experience first, marginal potential UX improvements and increased server performance second.

> 1. handshake (contains the session ID — here, zBjrh...AAAK — that is used in subsequent requests)
> 2. send data (HTTP long-polling)
> 3. receive data (HTTP long-polling)
> 4. upgrade (WebSocket)
> 5. receive data (HTTP long-polling, closed once the WebSocket connection in 4. is successfully established)

> Tips: [Socket.IO](http://Socket.IO) client is must compatible with the version of the Socket.IO server

**In brief, we adopt the Socket.IO as it's a wrapper around the WebSocket API and offers a variety of meaningful out-of-the-box features.**

## Using WebSockets with Next.js

Our webApp is build on Next.js, React code on Next.js runs in two environments: On the server (when building the page or when using SSR) and on the client.

The global WebSockets object is a feature that is only available on the browser and is not present on the server. That’s why we can’t create a WebSockets channel on Server side, but we want to keep taking advantage of the SSR: Speed up page first rendering.

We have two forking paths here:

1. Continue to fetch the rest api on the server side during the first rendering and then update the status via WebSockets channel on the client side (Make sure to share the same data structure of response)
2. Set up a WebSockets client in Node.js via importing websocket package, but it’s over hack and too complicated within `getServerSideProps`

**We decided to follow the first path. WebSocket Integration with Polling as a fallback on client side.**

## Errors Handling

Before such a major technical refactoring goes live, we establish our confidence in a reliable error catching mechanism and fallback mechanism.

We often assume that our WebSockets connections fail due to a variety of circumstances, and we have discussed and developed specific mechanisms to handle such situations

- Reconnect strategy
  - times / interval
- Fallback strategy
  - when to fallback to Polling

### HeartBeat:

Socket.io does that automatically handle this. In their circles the concept is referred to as a **heartbeat** mechanism instead of ping/pong. via `pingInterval` and `pingTimeout` as config.

#### Currently issues we known:

When a browser tab is not in focus, some browsers (like [Chrome](https://developer.chrome.com/blog/timer-throttling-in-chrome-88/#intensive-throttling) throttle JavaScript timers, which could lead to a disconnection by ping timeout in Socket.IO v2, as the heartbeat mechanism relied on setTimeout function on the client side.
As a workaround, you can increase the pingTimeout value on the server side:

```js
const io = new Server({ pingTimeout: 60000 });
```

Please note that upgrading to Socket.IO v4 (at least `socket.io-client@4.1.3`, due to [this](https://github.com/socketio/engine.io-client/commit/f30a10b7f45517fcb3abd02511c58a89e0ef498f) should prevent this kind of issues, as the heartbeat mechanism has been reversed (the server now sends PING packets).

## Authorization ticket

The WebSocket protocol (even Socket.IO) doesn’t handle authorization or authentication. Practically, this means that a WebSocket opened from a page behind auth doesn’t “automatically” receive any sort of auth; we need to take steps to also secure the WebSocket connection.

Normally, we would add the **ticket/token** to the request header

#### Can we send a HTTP headers in WebSocket client API ?

Short answer: **No, only the path and protocol field can be specified.**

WebSocket client API doesn't allow to send custom header, they allow us to set exactly one header, namely `Sec-WebSocket-Protocol`, i.e. the application specific subprotocol. We could use this header for passing the bearer token.

> How about we set `Sec-WebSocket-extensions` ?
> This isn't an extension that you specify explicitly in your JavaScript code. If the browser supports this extension it will automatically add the deflate-frame token to the Sec-WebSocket-Extensions header. If the server supports it as well then it will specify the same token in its response.
>
> Here's a discussion thread about it: https://github.com/whatwg/html/issues/3062

**Then with `extraHeaders` in SocketIO**

This only works if `polling` transport is enabled (which is the default). Custom headers will not be appended when using websocket as the transport.

```js
// client-side
const socket = io({
  transportOptions: {
    polling: {
      extraHeaders: {
        'x-clientid': 'abc',
      },
    },
  },
});

// server-side
const io = require('socket.io')();

// middleware
io.use((socket, next) => {
  let clientId = socket.handshake.headers['x-clientid'];
  if (isValid(clientId)) {
    return next();
  }
  return next(new Error('authentication error'));
});
```

## Data Flow

We envisioned the data flow for the entire app with WebSocket integration.
Basically, we use the Pub/Sub pattern, but we implement it as a variant in the React ecosystem.

We have a websocket data source origination place, which is a Provider component that will also receive the initial data from the server side (SSR data source). In the provider, we fuse the two data sources and expose them to any subscribers.
The subscription method is not really important, we provide various ways such as `Hook` or `Context.consumer`, we think that the details of data storage are not the focus for this post.

- `WebSocket.Provider` as a Pub
- `useSocket` hook / `WebSocket.Consumer` as a Sub

### Doubts

We have listed some points that we have not yet achieved or have yet to get here.

1. Could we keep single one ws instance when root pages changes in Next.js.
1. We have not yet taken advantage of the duplex feature of websocket and there may be an opportunity to apply it to other interaction flows of our application.
1. Could we combine the react server component in the future to make our application more interactive and smooth user experience.

## Additional Content: Accurate timer

### Background

Our checkout has a countdown timer to indicate how much remaining time for the user to pay. It's implemented by pure JS running in the browser, and for a long time its remaining time calculation was always weird.
We took the opportunity of this refactoring and decided to do some research and make the timer work well.

**Why is it not accurate?**

On most browsers, tags that are inactive have a low priority for execution, which may affect the JavaScript timer.

Because we used setTimeout() or setInterval() before. [They cannot be trusted](https://stackoverflow.com/q/196027/1048572), there are no accuracy guarantees for them. [They are allowed to lag](https://stackoverflow.com/a/10740558/1048572) arbitrarily, and they do not keep a constant pace but [tend to drift](https://stackoverflow.com/q/985670/1048572) (as you have observed).

### How can we create an accurate timer?

Use the [Date](https://developer.mozilla.org/en/JavaScript/Reference/Global_Objects/Date) object instead to get the (millisecond-)accurate, current time. Then base our logic on the current time value, instead of counting how often your callback has been executed

> I know there are some articles that touches on the subject regarding how JS timers work:
>
> - [Accuracy of JavaScript Time](http://ejohn.org/blog/accuracy-of-javascript-time/)
> - [How JavaScript Timers Work](http://ejohn.org/blog/how-javascript-timers-work/)
>
> while there are lots of excellent information in there but to an incoming onlooker seems convoluted and lost in its overall projection of the issue and or a solution.

**So, let me get this straight**
What we are trying to accomplish is make a relatively accurate timer, or rather a timer with automatic correction of errors if there are deviations occurs.

## Looking forward

As we integrate with the WebSocket in out payment SDK, we can provide more responsive data feedback to our users and reduce our server resource consumption in the foreseeable future as access grows.
In the future, we will continue to work on enhancing our payment functions to support our business in a way that is no longer a bottleneck at the technical level.

## Reference

1. https://ably.com/blog/websockets-vs-sse
2. https://stackoverflow.com/questions/4361173/http-headers-in-websockets-client-api
3. https://developer.mozilla.org/en-US/docs/Web/HTTP/Protocol_upgrade_mechanism
4. https://socket.io/blog/engine-io-4-release/#heartbeat-mechanism-reversalhttp://Engine.IOhttps://socket.io/blog/engine-io-4-release/#heartbeat-mechanism-reversal
   - https://github.com/socketio/socket.io/issues/2924
   - https://github.com/socketio/socket.io/issues/3507

This post comes from a technical doc I shared within the Crypto.com, after...

WebSocket Integration of Crypto.com Pay


这篇文章来源于我曾经在 CODING 负责构建 BBF 中间服务层时记录总结的演进方案，在数据脱敏之后公开出来，希望给予有类似业务需求的同学或团队一点灵感。

## 演进背景

在传统的前后端分层设计中，通常是前端（Web/App）直接访问后端服务；而后端方面，随着容器化技术的发展，Monolithic 的架构正逐渐向 Microservices 进行转移，而这种架构下的微服务之间进行相互调用，得到最终的调用结果供前端消费。

在一般业务需求的驱动下（UI 驱动），前端消费的数据常见的情况是跨多个微服务提供的数据，为了减轻 Client 端的网络消耗（HTTP），往往需要 Server 端提供整合数据的能力，以及附加一些针对 UI 的逻辑处理。

源于 Domain-Driven Design 的 Server 端自然与面对 UI Driven 的 Client 端之间有需要协调的部分。特别是针对当时的业务形态：研发规范（Workflow）的场景，在各个其他业务线独立能力的基础上增加自有的逻辑，以及横跨多个业务交互的场景。

<figure>
  <img
  src="https://cdn.nanyang.io/images/bff-infrastructure-00.png"
  alt="简化后的架构图">
  <figcaption>简化后的架构图</figcaption>
</figure>

从本质上我们需要让业务的研发工作（FE/BE）更符合 SoC

For Frontend：

1. 可定制化根据 UI 的展示数据，对 API 返回的数据进行适当裁剪和整理
2. 根据特定业务需求，聚合多个微服务提供数据
3. 为微服务之间做转发数据，获得最终业务需要的数据
4. 对频繁请求或场景的数据进行缓存

For Backend：

1. 微服务架构内部的演进以及微服务的拆分后的治理，减少对前端的影响
2. 跨微服务的 API 上升到 BFF，消除业务代码依赖

## 演进方案

我们可以在前后端架构模型之间添加中间层以解决和满足我们上述的痛点/需求，在业内这层也被叫做 BFF (Backend For Frontend)，这里的 For Frontend 代表了前端作为最终消费者的角色，在一般的场景下，这一层由前端团队负责，但收益方是包括前后端的。

加入了 BFF 的前后端架构中，最大的区别就是前端服务不再直接访问后端微服务，而是通过 BFF 层进行访问。从微服务的角度来看，由于有关 UI 逻辑的数据在 BFF 层进行了处理，微服务之间的相互调用更少了。

<figure>
  <img
  src="https://cdn.nanyang.io/images/bff-infrastructure-01.png"
  alt="加入 BFF 的架构">
  <figcaption>加入 BFF 的架构</figcaption>
</figure>

### BFF 节点的细分粒度

常见的几种拆分方式

1. 端级：以 PC，Mobile 来区分
2. 组织架构级
3. 业务级：以不同业务主体为拆分方式

以 CODING 的业务和组织架构，我们可以拆分 BFF 为 Vcs-BFF / CI-BFF / CD-BFF 等

### 如何对接上游前端服务

这里面临常见的技术选型，主要围绕在权衡 RESTful API 和 GraphQL。

在这里我们将选用 GraphQL，并支持 fallback 一些 RESTful API

### Why GraphQL?

作为一种 Query Language，GraphQL 具有以下特点：

1. 支持精确的数据定制能力。消费者在一个 end point 中自由组合需要的资源，减少不必要的多次请求以及多 API 调用的复杂性
2. 代码即文档，所有的 query 以及 mutation 自动生成 schema (文档)
3. 无需获取全部的数据集，通过 schema 和 resolver 之间的映射关系，只需要在对应的 resolver 中编写数据的获取逻辑
4. 数据的类型系统配合前端，提高开发效率

> [GraphQL vs RESTful API](https://www.notion.so/63788b000a724d38b530b79f0ac79d0e)

### 如何对接下游微服务

对接下游的后端微服务存在这几点问题

1. 对接多个不同技术栈的微服务
2. 如何管理组织这些调用，以及调用失败的情况

以 RPC 或者 HTTP 等通用协议抹平各技术栈实现的差异。利用一些 async stream 控制库简化异步调用的复杂性，在 BFF 进行调用失败的容错，定制错误信息返回前端。

综合以上的架构图:

![image](https://cdn.nanyang.io/images/bff-infrastructure-02.png)

CODING BFF 主要满足了以下功能

1. 服务聚合：为前端提供业务数据的聚合点，屏蔽微服务之间复杂的调用链
2. 数据清洗：在 BFF 聚合/转发/过滤后端 API 的数据，重新构建符合 UI 驱动模型的数据结构
3. 业务隔离：针对每一个独立的业务，都有其专用的 BFF Server 做逻辑处理
4. 应用缓存
5. 未来：在这层改造进行支持 SSR or hydrate 渲染；支持 react server component

## 实现路径

![image](https://cdn.nanyang.io/images/bff-stack.png)

### 服务端 Server

Server 这里采用 Node 开发，原因是考虑业务迭代效率的因素，Client 和 Server 采用统一技术栈，周边生态可复用，支持未来的同构代码/SSR/以及更高能力的混合渲染；以及这层主要承担的职责是网络 I/O bound，不会涉及到大量的 CPU bound，语言层面 Node 可以胜任 BFF 的绝大部分场景

这里使用 Koa 作为 HTTP middleware framework，利用 U 型中间件系统处理响应以及便捷实现后置处理逻辑，借助 Co 结合 Generator，增强异步控制流的能力；Koa 没有捆绑任何 middleware（对比 Express），在这里我们将根据需求使用一些中间件。

由于采用 GraphQL 作为 Client 和 Server 交互的方式，我们可能需要一个支持 GraphQLSpec 的解决方案，比如 Apollo，当然也可以直接使用官方的 graphql 来解决，解决方案层出不穷，其实在这里我们只看重两个点：

1. 可执行的 GraphQL Schema 和 Resolver，结合响应查询
2. 接受 GraphQL Request 的能力，结合 Schema 返回结果的逻辑

在这里我们将使用 Koa 与 Apollo 的集成：[apollo-server-koa](https://www.npmjs.com/package/apollo-server-koa)

Server 的入口

```tsx
import { graphiqlKoa, graphqlKoa } from 'apollo-server-koa';
import * as koa from 'koa';
import * as koaBody from 'koa-bodyparser';
import * as koaLogger from 'koa-logger';
import * as koaRouter from 'koa-router';
import { APP_NAME, APP_PORT } from './config';
import { Schema } from './schema';
import { Logger } from './utils';

const app = new koa();

app.use(koaBody());
app.use(koaLogger());

const _router = new koaRouter();

_router.get('/graphql', graphqlKoa({ schema: Schema }));
_router.post('/graphql', koaBody(), graphqlKoa({ schema: Schema }));
_router.get('/graphiql', graphiqlKoa({ endpointURL: '/graphql' }));

app.use(_router.routes());
app.use(_router.allowedMethods());

app.listen(APP_PORT, () =>
  Logger.log(`${APP_NAME} running at ${APP_PORT} ports.`)
);
```

### Resolver 编写

Resolver 包含了从后端微服务中获取数据/转换/过滤等逻辑，在这里使用 gRPC 以 proto3 约定在 Server 进行注册并与微服务交互。

- GraphQL is in charge of setting up a contract with the outside world, while gRPC is in charge of communication between micro-services within the company.

例如常见的获取 branchList 的 resolver

`resolvers/branchList.ts`

```tsx
import BranchClient from '@services/branch';

const client = BranchClient();

interface Params {
  branchName: string;
}

export default (root: Root, params: Params) => {
  return new Promise((resolve: Resolve, reject: Reject) => {
    client.branchList(params, function (err: errorData, response: Response) {
      if (err) {
        return reject(err);
      }

      // do anything...
      resolve(response);
    });
  });
};
```

`@services/branch.ts`

```tsx
import fs from 'fs';
import * as grpc from 'grpc';
import * as protoLoader from '@grpc/proto-loader';

const proto = protoLoader.loadSync(__dirname + '/branch.proto');

const BranchServiceClient =
  grpc.loadPackageDefinition(proto).branch.branchService;

export default () => new BranchServiceClient();
```

### Schema 编写

以往常见的使用 `graphql` 编写 Schema 类似于这样

`schema.graphql`

```tsx
import {
  graphql,
  GraphQLSchema,
  GraphQLObjectType,
  GraphQLString,
} from 'graphql';

new GraphQLSchema({
  query: new GraphQLObjectType({
    name: 'RootQuery',
    fields: {
      defaultBranch: {
        type: GraphQLString,
        resolve() {
          // do anything
          return 'main';
        },
      },
    },
  }),
});
```

在经历项目复杂，查询 fields 层级嵌套会很深，不利于解耦 query 与 resolver

这里利用 `graphql-tools` 来 parse schema 中 query 与 resolver 的对应关系，生成上述 schema

```tsx
// schema.graphql
type Query {
  branchList(page: Int limit: Int): Branch
}

schema {
  query: Query
	// mutation: Mutation
}
```

`graphql/index.ts`

- Apollo Server 现在内置了 [graphql-tools](https://www.apollographql.com/docs/apollo-server/api/graphql-tools/)

```tsx
import * as path from 'path';
import * as fs from 'fs';
import { makeExecutableSchema } from 'apollo-server';
import resolvers from './resolvers';
const schemaPublic: string = fs
  .readFileSync(path.resolve(__dirname, './schema/schema.graphql'))
  .toString('utf8');

export const schema: any = makeExecutableSchema({
  resolvers,
  typeDefs: [schemaPublic],
});
```

### 客户端接入 Client Access

理论上支持 GraphQL 的 request 库都可以满足，但我们想对前端 DX 再添加些能力

1. `Apollo Client`
2. `SWR`
3. `react-query`

以上三者都能覆盖我们当前的前端场景，但 `Apollo` 相比于 `SWR` 与 `react-query` 多出 20KB 左右的 bundle size，其中多出来的大部分功能在我们的业务场景下可能都不需要

而采用 stale-while-revalidate 思想的 `SWR` 与 `react-query` 提供了更多能切实提供前端 DX 的能力，以及支持 fallback 到 RESTful 的能力

1. Caching mechanism
2. Window Focus Refetching
3. API for refetching queries
4. Lazy queries
5. Error handling
6. 更好的 DevTool 状态显示

> 详细的 [comparison](https://react-query.tanstack.com/comparison)

具体的接入例子不再列举，和常见更改 fetch 库的方式基本一致。

这里我们为了在 Client 得到与在 Server 端一致的类型定义，可以利用 `graphql-codegen` 根据 Server 定义好的 Schema 生成对应的 TypeScript typings

### BFF 可能会出现的坏情况

> 待详细补充

1. 多个 BFF 可能会出现重复代码
2. 趋向于 [ESB](https://en.wikipedia.org/wiki/Enterprise_service_bus)：BFF 中编写了过多业务能力的逻辑
3. 性能问题：调用十几个 API 来拼装数据，以及转发多次的情况

### More

部署

监控/可用性

鉴权

缓存

Why not Relay

## 总结

在当前大型项目的后端微服务化和前端微服务化的架构发展中，其实核心是围绕 关注点分离(Separation Of Concerns) 的思想，架构的各个环节的 Pattern 也被讨论出来，BBF 既有助于解耦 Microservice, 也有助于前端更专注于提升 UX，以及更大的自主权对于 API 和 数据格式 的定义，更快的适应未来的变化和需求，而 FE Engineer 的责任和边界也对应更加扩大。当然 BFF 也不属于一个完美的通用解决方案，服务于具体业务才是最重要的，本文只是提供一个思路，以及一些基本的架构设计。


这篇文章来源于我曾经在 CODING 负责 BBF 中间服务层时记录总结的演进方案...

CODING BFF 架构演进方案


In the last few months, I've been working on and building a React Data-Fetching library.

- Temporary name: react-retain

My To-Do list grew longer and longer as my research progressed. With implementing the features in it, I realized that it was necessary to record something about the React Suspense.

<br>

In brief, I wanna talk about how to take advantage of React Suspense, instead of how to use it.

This article assumes that you are already familiar with the following concepts:

- React 16/17/18 concepts of main topics (like Scheduling Model/Rendering Model)
- The pain points for UI Engineering

<br>

## 🙋‍♂️Hang on, What is React Suspense At First?

Suspense is not a data fetching library in React. It's a mechanism for data fetching libraries to communicate to React that the data a component is reading is not ready yet.

<br>

This is an official detailed description for library authors:

[Suspense for Data Fetching (Experimental) - React](https://reactjs.org/docs/concurrent-mode-suspense.html#what-is-suspense-exactly)

> Suspense for data fetching is still developing and the behaviors could be changed.

<br>

Let me talk about more benefits of that.

### Benefits:

Suspense is an improvement to the developer experience when dealing with asynchronous data fetching within React applications

Suspense also transforms the way we think about loading states, which shouldn't be coupled to the fetching component or data source (Which means it beyond API data fetching and can be applied to any async data flow)

> If you have read the React Roadmap carefully, you will see that there is already an official description of this part at the end of 2018
> [React 16.x Roadmap - React Blog](https://reactjs.org/blog/2018/11/27/react-16-roadmap.html#react-16x-mid-2019-the-one-with-suspense-for-data-fetching)

<br>

## What is Suspense Actually Doing?

React has been throwing around this idea that a component can throw a Promise.

**throw** is very important here, it can't **return** a Promise, it must **throw** it to indicate it's "async".

If the **nearest** ErrorBoundary (which Suspense is) catches an rejected (or unresolved) Promise, then it displays it's fallback.

When the Promise it caught resolves, it renders it's children

That's what Suspense does, tremendously simple when you think about what it's actually doing.

<br>

Let's look at a few examples of React official usage of Suspense

These can fetch the data source/component and suspend these.

- React Lazy: [source code](https://github.com/facebook/react/blob/54e170c79493dea734b95b0fddbf8f0bfc99bff7/packages/react/src/ReactLazy.js#L115)
- React Relay : [source code](https://github.com/facebook/relay/blob/140b66ee801c6096bf786504d9d68df5319fa68e/packages/react-relay/relay-hooks/QueryResource.js#L368-L382)
- React Cache (unstable): [source code](https://github.com/facebook/react/blob/54e170c79493dea734b95b0fddbf8f0bfc99bff7/packages/react-cache/src/ReactCacheOld.js#L149)
- React Fetch (unstable): [source code](https://github.com/facebook/react/blob/54e170c79493dea734b95b0fddbf8f0bfc99bff7/packages/react-fetch/src/ReactFetchBrowser.js#L70)

<br>

Then let's write our implementation for a data fetching library.

```jsx
function SuspendPromise(promise) {
  let status = 'pending';
  let result;
  let suspender = promise.then(
    (r) => {
      status = 'success';
      result = r;
    },
    (e) => {
      status = 'error';
      result = e;
    }
  );
  return {
    read() {
      if (status === 'pending') {
        throw suspender;
      } else if (status === 'error') {
        throw result;
      } else if (status === 'success') {
        return result;
      }
    },
  };
}

// use
SuspendPromise(fetcher()).read(); // proxied data maybe better
```

And React Suspense handles throws

Suspense: [soure code](https://github.com/facebook/react/blob/54e170c79493dea734b95b0fddbf8f0bfc99bff7/packages/react-reconciler/src/ReactFiberThrow.new.js#L282-L433)

> BTW, When the data has been resolved, React internally will call the callback function to notify the component that the data has been resolved and ready to refresh.
> 
> **attachPingListener**: [facebook/react@0e100ed/packages/react-reconciler/src/ReactFiberThrow.new.js#L161-L190](https://github.com/facebook/react/blob/0e100ed00fb52cfd107db1d1081ef18fe4b9167f/packages/react-reconciler/src/ReactFiberThrow.new.js#L161-L190)

<br>

## And what happens in React 18?

When the user re-fetches data in a valid, stable UI, we wouldn't show a loading indicator again, It hardly a good UX, We'd prefer the old UI keep on the screen while new data fetching.

<br>

In React 18, State updates in two categories.

- Urgent
- Non-Urgent

Non-Urgent updates could be called **Transition updates**, it will update states in memory/in the background while keeping your existing UI on screen, and keeping your app responsive during large screen updates.

<br>

React provides two API (for the time being) to explicitly choose how to transition updates:

- `startTransition`
- `useTransition` (hook)

(In fact, the two API's do the same thing. `startTransition` is a common function, it could be called in most library code, and you can only use `useTransition` inside of a component, If you do use the hook without using the **_isPending_** flag then there's a bit of unnecessary work because React still re-render to update the **_isPending_** value. And it's just a hook, so follow the hook rules)

<br>

`Suspense` and `startTransition`/`useTransition`, they are independently useful features, and they are designed to work together.

If you don't use `startTransition`/`useTransition` when the page re-suspends during a refresh, React will replace the stale content with a placeholder(Suspense's fallback).

However, by wrapping the update with `startTransition`/`useTransition`, you're telling React that don't remove existing UI, just wait until the updated data has resolved and display new UI directly. (Whether you use `Suspense`)

> In the early experimental version, `useTransition` takes one parameter: **timeoutMs**. This indicates the amount of time you’re willing to let the in-memory state change run, before it suspend.
> As you probably don't want your existing UI to show indefinitely while your loading is pending.
>
> In the latest experimental version, `useTransition` no longer takes parameters, the timeout behavior will be controlled by react.
> And one more thing, Suspense has more features on the server in React 18.

<br>

## Conclusion

In this article, we've taken a look at what exactly Suspense does.

`Suspense` is an interesting concept that makes errors and async handling declarative.

> `Suspense` maybe is a stretch from [Algebraic Effects](https://overreacted.io/algebraic-effects-for-the-rest-of-us/)

<br>

Ideally, we throw the Promise when it isn't resolved, React catches that Promise (like `<Suspense>` and `<ErrorBoundary>` did), and remembers to retry rendering the component tree after the thrown Promise resolves.

In fact, If the Promise is resolved (which means the data is ready), and nothing is thrown. `<Suspense>` and `<ErrorBoundary>` will render their children, instead of fallback.

<br>

One thing that cannot be missed in this process which closer-to-reality is that React ensures that the re-rendering is idempotent.


In the last few months, I've been working on and building a React Data-Fetching library...

How To Take Advantage of React Suspense?


![img](https://cdn.nanyang.io/images/post:become-a-nicer-interviewer.jpeg)

<br>

Since the beginning of my career, I have interviewed over 70 candidates as an interviewer (2018 - 2021) and participated in the interview process of over 10 companies as a candidate.
Have some experience of my own.

## How to pick fit candidates

The principle of the interview is to pick out the right person for the corresponding job requirements, which is usually not covered by some specific technical questions in detail.

The principle is to try to keep it as practical as possible, for example by looking at skills that will be used in the real world.

<br>
<br>

The human mind always prefers certainty, and both the candidate and the interviewer are influenced by this underlying preference.

The interviewer prefers to examine the candidate's ability through definite and specific questions.

The candidate prefers to prove their ability by preparing answers to definite and specific questions.

<br>

However, is this the right way?

<br>

Undeniably, even the process of preparing answers to known questions is a good way to learn, but the perspective of knowledge obtained in this way is very one-sided, and the final answers corresponding to those questions are usually the answers summarized above the collection network, mostly missing the path of thinking from the source of the problem to the solution.

If your goal is to pick out candidates at the mid-level and above, do not use the above approach.

Because the value of mid-level engineers is in the way of solving problems, developing solutions on higher level, and excellent communication and understanding skills

<br>
<br>

Typically I would suggest that the requirements for a mid-level frontend engineer would be something like:

#### Would not require

- We won't ask you to master complex sorting algorithms, or even to write a complete bubble sort.
- We won't ask you to implement complex and obscure data structures, such as red-black trees.
- We won't ask you to master a wide variety of UI libraries, such as React / Vue / Angular / etc.

#### Would expect

- The candidate would be expected to be able to find and resolve bottlenecks in the code and be able to articulate trade-offs between cases.
- The candidate would be expected to master common data structures in UI engineering, such as arrays, maps, sets, and DOM trees, as well as common CS topics such as Big O notation and tree traversal, but more importantly to apply these principles in engineering practice to create better UI (faster and stronger).
- The candidate would be expected to understand the JavaScript language and its primitives, as well as the intent behind the UI lib abstraction concepts, such as how your implementation will handle cases of heavy IO operations, and consider edge cases and memory consumption.

<br>
<br>

### Soft skills

One more important thing is communication skills. I tend to ask a few wide-ranging questions during the process, and I pay particular attention to how the candidate is structured to answer those questions, and how the candidate reacts when they are more confused about the questions.

<br>

And is a CS degree required for software engineers?

As far as I know, 80% of CS exams (college) are not even related to computers. That's math, physics, statistics, math and more math.

The duty of most majors in university education in the modern education system is to teach the methodology of learning knowledge, not applied or research-based knowledge.

Programming is amazing in that it does not have a clear gate. When you choose this direction, you decide that you will continue learning for the rest of your life. So this position may depend on your passion for programming and persistent effort.

## Ending of the post

As an interviewer, I have met very nice interviewers and also very bad ones, so after a deep experience.
My thought is that every candidate is probably a treasure, and the most important ability of an interviewer is to find out what makes each person tick.


Since the beginning of my career, I have interviewed over 50 candidates...

Become a nicer interviewer



![img](https://cdn.nanyang.io/images/post:react-18.jpeg)

<br>

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

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



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

### 这个 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)


Memoization


在 React v16.7.0 alpha 版本里，提出了一个新的 Feature Proposal: Hooks ，对社区以及未来 React 周边生态发展所带来的影响是巨大的。

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

# What is the Hooks ？

Hooks 是 React 内部组件中的一系列特殊函数，直观带来的改变是引入 state、side effects function、或者其他 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` 的结合（但两者的 Render Model 完全不一样）

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://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`



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