ALGORITHM

COMPUTATION

CRYPTOGRAPHY

FRONTEND

GAME-THEORY

INVESTMENT

JS&TS

LINUX

MATHEMATICS

NODE

OTHERS

PROJECT-PRACTICE

REACT

THOUGHTS

古文整理

文史哲艺


Concerning the `useEffect` hook, [as described in the React official documentation](https://react.dev/reference/react/useEffect), it is sufficient. Unfortunately, `useEffect` is the most controversial API design in React. It is widely considered the most challenging and difficult-to-implement hook in actual projects, stemming from the contradiction between React's idealized design and the practical demands of development.

In this article, based on the prevailing community viewpoint, I will discuss my personal understanding of this issue: you should avoid using `useEffect`, as there are often better alternatives for most use cases.

## Side Effects: `useEffect`

`useEffect`, as the name implies, describes the side effects during the rendering of a component. To understand this hook, we must first comprehend what a side effect is.

> In functional programming, a "side effect" refers to any impact on the program's state other than the return value of a function. Functional programming emphasizes the concept of pure functions, where a pure function produces the same output for the same input conditions and has no side effects.

For example, consider a function simulating a bank statement query, requiring only two parameters: the account and a time range. It returns all the transaction records for the specified account within that time range. If it only returns the query result without any other operation, the function is pure:

```typescript
GetBankStatement(accountId, timeRange) {
  let data = ...... // fetch the data from the database;
  return data;
}
```

However, the bank's database is sensitive, and for security reasons, each query request must be monitored. Thus, in addition to returning the result, the function might log information about the query, such as the queried account and date:

```typescript
GetBankStatement(accountId, timeRange) {
  let data = ...... // fetch the data from the database;
  doLog("User XXXX queried account XXXX on date XXXX within the specified date range");
  return data;
}
```

Here, besides returning the query result, the function secretly logs the query operation, affecting the program's logging state. This operation represents a side effect.

In practical programming, side effects may include but are not limited to:

1. **Changing mutable data state:** Modifying external variables, object properties, or array elements to alter the program state.

2. **I/O operations:** Including reading/writing files, sending network requests, or performing operations in a database.

3. **Printing output or logging:** Outputting information to the console or logging details to a log file.

4. **Throwing exceptions:** Altering the normal program flow by raising exceptions.

5. **Modifying global variables:** Changing variable values in the global scope.

Functional programming aims to minimize or avoid side effects because they increase program complexity, reduce maintainability, and can lead to unpredictable behavior. Pure functions (functions without side effects) are easier to test, compose, and reason about.

By adhering to the principles of functional programming, code can be better controlled, readability can be improved, errors can be reduced, and programs can be more easily executed concurrently. In functional programming, it is generally encouraged to isolate side effects in specific areas of the program, such as using pure functions and the Single Responsibility Principle. If side-effect operations are needed, they can be handled at the edge of the program rather than in the core business logic.

Let's start with functional programming.

React, as a library for describing UIs, initially embraced some functional programming concepts. It uses JSX to encapsulate page elements into components with attributes. Given the input attributes, a component processes them logically and renders them as UI. This is similar to the mapping relationship between attributes and UI outputs in a function. In mathematical language, a function is a description of a mapping relationship: for a given, definite input, there is always a specific, unique output. This is also the requirement for functions in functional programming.

This is the ideal React component.

However, the problem is that although React borrows functional ideas, most components are not ideal components because each component may have its own state (`State`). States change with the internal logic of the component. According to the above definition, these changes are also considered side effects. Therefore, React does **not strictly** follow the idea of functions to describe the mapping relationship between input attributes and UI outputs.

## Two Main Use Cases

The React official documentation shows 10 examples to illustrate the use cases of `useEffect`. In my view, their use cases can be **essentially** divided into two main categories: initializing components and refreshing components.

### Initializing Components

Let's consider an example of developing an online bookstore app. We have a product book list displaying basic information such as book title, author, and price.

```typescript
function BooksList() {
  const [listData, setListData] = useState([]);
  return (
    <ol>
      {listData.map((item, index) => (
        <li>
          <h2>{item.title}</h2>
          <p>{item.author}</p>
          <p>{item.price}</p>
        </li>
      ))}
    </ol>
  );
}
```

When the app starts, this component is mounted, and its initial data state `listData` is an empty list, so it doesn't render anything.

Now, if I want the app to push the latest book list to the user upon launch, I need to fetch data from the server, initialize the component, and provide the fetched data as the initial data value for `listData`.

Here, `useEffect` provides a way to execute side effects **only after the component is first mounted**: by setting the dependency array to an empty array. Let's modify the code:

```typescript
function BooksList() {
  const [listData, setListData] = useState([]);

  useEffect(() => {
    fetch('https://my-api.com/get-latest-books')
      .then((res) => {
        setListData([...res.json()]);
      });
  }, []);
  // Here, the effect runs only once after the component is first mounted,
  // fetching data from the server, setting it to the state, and rendering it.
  // This way, the component gets an initial value, completing its initialization.

  return (
    <ol>
      {listData.map((item, index) => (
        <li>
          <h2>{item.title}</h2>
          <p>{item.author}</p>
          <p>{item.price}</p>
        </li>
      ))}
    </ol>
  );
}
```

Now, when `BooksList` is mounted, it executes the `fetch` operation to get initial data, updates `listData`, and renders the initial data, completing the component initialization.

Now, let's say I want to provide feedback to the user while the data is loading. I want to display a "Loading..." message and a loading animation during the fetch operation, and then display the list once the data is loaded. How do I achieve this?

We'll add another state, `isLoading`, to indicate whether the list is currently loading. If it is loading, show the loading animation and text. After loading, display the list and unset the loading state.

So, the code is modified as follows:

```typescript
function BooksList() {
  const [listData, setListData] = useState([]);
  const [isLoading, setIsLoading] = useState(false);

  useEffect(() => {
    setIsLoading(true);
    fetch('https://my-api.com/get-latest-books')
      .then((res) => {
        setListData([...res.json()]);
        setIsLoading(false);
      });
  }, []);

  return (
    <>
      {isLoading ?
        <div>
          <LoadingAnimation />
          <p>{"Loading..."}</p>
        </div>
        :
        <ol>
          {listData.map((item, index) => (
            <li>
              <h2>{item.title}</h2>
              <p>{item.author}</p>
              <p>{item.price}</p>
            </li>
          ))}
        </ol>
      }
    </>
  );
}
```

In this example, `fetch` and `setIsLoading` are part of the effect executed when the component is mounted and rendered. Here, the effect provides an indication of the loading logic during the initial rendering of the component.

### Accompanying Component State Refresh

A commonly encountered scenario is pagination.

For instance, I have a book list page, simplified as follows:

```typescript
export default function BooksListPage() {

  const [listData, setListData] = useState([]);
  const [currentPage, setCurrentPage] = useState(1);

  const handleLoadListData = (pageNum: number) => {
    fetch(`https://my-api.com/books-list/${pageNum}`)
      .then((res) => {
        setListData([...res.json()])
      })
  }

  useEffect(() => {
    handleLoadListData(currentPage);
  }, [])

  return (
    <main>
      <BooksList data={listData} />
      <p>{`Current Page: ${pageNum}`}</p>
      <button
        onClick={() => setCurrentPage(currentPage - 1)}
      >
        {"Previous Page"}
      </button>
      <button
        onClick={() => setCurrentPage(currentPage + 1)}
      >
        {"Next Page"}
      </button>
    </main>
  )
}
```

The above code represents pagination for the `BooksList` component. It includes a `currentPage` to indicate the current page number. Based on this page number, the API is called to load the corresponding list. Now that the initialization of the component is done, how do we implement loading the list corresponding to the new page number when the "Previous Page" or "Next Page" button is clicked?

Firstly, note that we are changing the `currentPage` state, and loading the corresponding list is an operation influenced by the changed state, modifying the `listData` state at the same time. In essence, loading the corresponding list is an effect.

Therefore, we can set up a `useEffect` with a loading new page list effect. The condition for this effect to take place is a change in `currentPage`.

```typescript
export default function BooksListPage() {

  const [listData, setListData] = useState([]);
  const [currentPage, setCurrentPage] = useState(1);

  const handleLoadListData = (pageNum: number) => {
    fetch(`https://my-api.com/books-list/${pageNum}`)
      .then((res) => {
        setListData([...res.json()])
      })
  }

  useEffect(() => {
    handleLoadListData(currentPage);
  }, [])

  useEffect(() => {
    handleLoadListData(currentPage)
  }, [currentPage])

  return (
    <main>
      <BooksList data={listData} />
      <p>{`Current Page: ${pageNum}`}</p>
      <button
        onClick={() => setCurrentPage(currentPage - 1)}
      >
        {"Previous Page"}
      </button>
      <button
        onClick={() => setCurrentPage(currentPage + 1)}
      >
        {"Next Page"}
      </button>
    </main>
  )
}
```

Now, when the `currentPage` state changes, it automatically executes the effect to load the corresponding list. This achieves the refreshing of the component's state.

### Drawbacks

Both of the above use cases have a strict prerequisite: **effect operations must be idempotent**. Idempotence means that for an operation, the initial operation and subsequent operations must be entirely equivalent.

For example, in database operations, read (`GET`), search, delete, and update (`PUT`, `POST`, `DELETE`) are idempotent operations. When we query data from the database, the database's state does not change. The first query for specific data and subsequent queries for the same data yield equivalent results. Therefore, querying data is an idempotent operation.

However, when we perform create (`POST`), delete (`DELETE`), or update (`PUT`) operations on data, the state of the affected data changes: new data is added, existing data is deleted, or existing data is modified. These operations are non-idempotent.

This is where the dilemma of `useEffect` lies.

React, initially designed as a library for declarative UI construction, primarily focuses on the relationship between input data flow, state data flow, and output UI. It relies on the unidirectional data flow of input → state → output to produce the final result.

Since the input data flow is dynamic and can change at any time, and states can change at any time based on internal business logic, and states' uncertainty determines the uncertainty of UI rendering results:

> **Note:** For performance reasons, even after updating the state to the latest data using `setState`, React may not immediately render the UI based on the latest state. It waits to collect enough latest states before batch updating and rendering. For more details, refer to the official documentation.

So, React cannot accurately determine when a component will be re-rendered based on state changes and cannot predict how many times it will be re-rendered. In other words, you cannot precisely anticipate the next step after an operation, whether the component will be refreshed or re-rendered.

Therefore, if you treat a non-idempotent operation as an effect, it can lead to inconsistencies between data and UI

.

On Twitter and GitHub, developers often complain that in debug mode, `useEffect` is executed twice, leading to bugs. In reality, they completely misunderstand the actual purpose of `useEffect` and incorrectly use it as an event listener for state changes.

Simply remembering this rule can help avoid misusing `useEffect`:

> The effect of `useEffect` should only be used for idempotent view initialization and view refresh. Beyond this, it has no other purpose and should not be used for any business logic.

Although this statement might sound absolute and somewhat harsh, it can fundamentally prevent misuse of `useEffect`.

For example, if you use a non-idempotent operation as an effect:

```typescript
function BooksManager() {
  const [listData, setListData] = useState([]);

  const handleAddNewBook = (book) => {
    setListData((prevListData) => [book, ...prevListData]);
  };

  useEffect(() => {
    axios.post("https://my-api.com/add-book", {
      body: listData[0],
    });
  });

  // ....
}
```

What's wrong with the above code?

It attempts to immediately sync the added book to the server after adding a new item to the data list. However, "Adding a new book" itself is not an idempotent operation. This effect not only triggers after the `listData` state changes but also after the parent component re-renders, with an unpredictable number of triggers.

Now, let's add a dependency array to this `useEffect`, restricting it to trigger only after `listData` changes. How about this?

```typescript
useEffect(() => {
  axios.post("https://my-api.com/add-book", {
    body: listData[0],
  });
}, [listData]);
```

This approach is very risky.

Because once I execute

```typescript
setListData([...listData]);
```

The data table itself has not changed, and there is no new book added. Even though the comparison of various rendering nodes in the Diff process has not changed, the reference to the array in the state data has changed. It might still trigger the effect, causing the repetitive addition of existing books.

### Point of No Return

After all that discussion, let me share my personal perspective on `useEffect`. Unfortunately, `useEffect` is a fundamentally flawed and irreparable mistake. Numerous bugs and accidents have resulted from `useEffect`, and it has become the cause of various issues.

There is a well-known incident on Twitter's web platform where developers forgot to add a dependency array to `useEffect`, leading to a massive number of GET requests, eventually crashing Twitter's servers. Initially, the cause of this bug was not identified, and the event of Twitter's service overload was mistakenly attributed to a network crawler attack launched by competitors. As a response, Elon Musk set a daily browsing limit for Twitter, resulting in an unintentional incident.

Due to its roots in React's core design philosophy, this kind of error is irreversible.

I once came across an answer on Zhihu (Chinese Q&A platform) that pinpointed the problem well:

> The essence of GUI is a state machine with a lifecycle. It is the result of the interaction between state data and the view, not a simple F(x).

The writing style of `useEffect` in React is indeed awkward, and it made many fundamental mistakes from the beginning. Various optimization techniques and hooks introduced later are just patching up these issues.

For instance, the uncertainty of states leads to the uncertainty of rendering, sometimes causing redundant rendering, and developers have to use methods like `useMemo`, `useCallback`, `React.memo` to avoid redundant rendering. All optimizations must be done manually, adding to the cognitive burden and making React's performance rank lower compared to other frameworks.

Frameworks like Vue do not have these issues. Vue's performance is even better than React.

However, React, despite its many pitfalls in this regard, is still considered an excellent front-end framework after years of development. When learning React, it is crucial to learn from these "pitfalls" and avoid such practices, rather than getting bogged down in the details of peculiarities in writing.

As one wise developer summarized:

> Many people mentioned the most critical point below: the state in asynchronous side effects should not be out of sync, `useEffect` is not a lifecycle, not `didUpdate`. Dependencies are just a helpless move limited by the nature of the JavaScript language, and it's not a feature. Therefore, no business logic should depend on dependencies to be implemented.


The article discusses the challenges and pitfalls of using useEffect in React, emphasizing its proper application for idempotent view initialization and refresh, cautioning against non-idempotent operations to avoid inconsistencies between data and UI.

The Usages and Traps of useEffect in React


对于 useEffect 这个 hook，[我认为 React 官方文档中所述备矣](https://react.dev/reference/react/useEffect)。但不幸的是，对于 useEffect，它是 React 中受到争议最大的 API 设计。人们普遍认为他是 React 中最难以理解、最难以在项目中实际投入使用的 hook，源于 React 过于理想化设计与实际开发需求脱节之矛盾。

本文在采取社区的主流观点后就此问题来谈谈我的个人理解：你应当避免使用 useEffect，它在大多数用途中可以以另一种更好的方案替代之。

## 副作用：Effect

useEffect，顾名思义：它描述的是组件渲染时的副作用。要理解这个 hooks，我们必须先理解什么是副作用。

> 在函数式编程中，"副作用" 是指函数除了返回值之外对程序状态产生的任何影响。函数式编程强调纯函数的概念，而纯函数是指在相同的输入条件下总是产生相同的输出，并且没有副作用。

举个例子，假设有一个函数，模拟银行查询流水记录，只需要输入账号、时间范围两个参数，就返回这段时间范围内指定账户的所有流水记录。如果只返回查询结果，什么也不操作。函数大约如下：

```typescript
GetBankStatement(accountId,timeRange){
  let data = ...... // fetch the data from database;
  return data;
}
```

这种函数叫纯函数。

但是，银行的数据库是很敏感的数据信息，为了防止滥用查询职权，要求必须监视每一个查询请求，每查询一笔流水记录，就必须在日志中记录何时查询的、被查询账户等信息。

```typescript
GetBankStatement(accountId,timeRange){
  let data = ...... // fetch the data from database;
  doLog("xxxx 在 xxxx 年 xxxx 日 查询了 xxxx 的账户，被查询的日期范围为 xxxx");
  return data;
}
```

它除了返回查询结果，还暗自做了查询日志记录，记录每一笔查询操作。这种操作就是除了返回结果值以外，也对程序日志记录的状态造成了影响，这种操作就是副作用。

在实际编程中，副作用可能包括但不限于：

1. **改变可变数据状态：** 函数修改外部变量、对象属性或数组元素，从而改变程序状态。

2. **I/O 操作：** 包括读写文件、发送网络请求、在数据库中进行操作等。

3. **打印输出或日志记录：** 将信息输出到控制台或记录到日志文件。

4. **抛出异常：** 改变正常的程序流程，引发异常。

5. **修改全局变量：** 改变全局作用域中的变量值。

函数式编程试图最小化或避免副作用，因为它们会增加程序的复杂性、降低可维护性，并且可能引发不可预测的行为。纯函数（无副作用的函数）更易于测试、组合和推理。

通过遵循函数式编程的原则，可以更好地控制代码，提高可读性，减少错误，并使程序更容易并发执行。在函数式编程中，通常鼓励将副作用隔离在程序的特定区域，例如通过使用纯函数和单一职责原则。如果需要进行有副作用的操作，可以在程序的边缘处理，而不是在核心业务逻辑中。

首先我们就从函数式编程来入手

React 作为描述 UI 的基础库，早期拥抱了函数式编程的部分思想：它使用 JSX 将页面元组封装成一个具有属性的组件，给定该组件的属性输入，则组件将输入属性进行逻辑处理后渲染成 UI。实际上这类似于函数中属性到输出 UI 直接的映射关系。大概为

$$
F(props) => UI
$$

在数学语言中，函数（Function）是对映射关系的描述：对于给定的确定输入，总是有确定的、唯一的输出。这也是函数式编程中对函数的要求。

这就是理想的 React 组件。

但问题是：React 虽然借鉴了函数式思想，但大多数组件并不是理想组件，因为每个组件可能会有自己的状态 (State)，而状态是会跟着组件内部逻辑发生改变的，按照上面的定义，这种改变也叫副作用，所以 React **并不是** 按照严格的函数思想来描述输入属性与输出 UI 的关系的。也就是说，输入属性并不一定严格映射到唯一的 UI 输出。

## 两大用途

useEffect 在官方文档中展示了 10 类样例来展示用途。在我看来，其实它们的用途 **本质** 上可以分为两大类：初始化组件和刷新组件。

### 初始化组件

考虑我们开设一个在线书店的 APP，我们有一个商品书目列表，它标注了书名、作者、价格的基础信息。

```typescript
function BooksList() {
  const [listData,setListData] = useState([]);
  return (
    <ol>
      {listData.map((item,index) => (
        <li>
          <h2>{item.title}</h2>
          <p>{item.author}</p>
          <p>{item.price}</p>
        </li>)
      )}
    </ol>
  )
}
```

当 App 启动后，这个组件被挂载时，它的初始数据状态 `listData` 为空列表，它当然什么也不会渲染。

那么，如果我希望 App 一启动后，就给用户推送最新上市的书目列表，那么我们就要在组件挂载后，从服务端拉取数据，给组件初始化一下，赋予拉取的数据作为一个初始的数据值放到`listData`中。

所以，`useEffect` 提供了一种 **只在组件首次挂载后执行** 的副作用方法：把依赖数组置为空数组即可。把上面的代码再修改一下，大概写成如此：

```typescript
function BooksList() {
  const [listData,setListData] = useState([]);

  useEffect(()=>{
    fetch('https://my-api.com/get-latest-books')
      .then((res)=>{
        setListData([...res.json()])
      });
  },[])
  // 在这里，effect 只会在组件首次挂载时拉取服务器数据，
  // 设置到 state 中并渲染出来。
  // 这样组件就获得了一个初始值，也就完成了组件的初始化。

  return (
    <ol>
      {listData.map((item,index) => (
        <li>
          <h2>{item.title}</h2>
          <p>{item.author}</p>
          <p>{item.price}</p>
        </li>)
      )}
    </ol>
  )
}
```

这样，当 `BooksList` 被挂载后，会执行 `fetch` 操作获取初始数据，更新到 `listData` 中，并且把初始数据渲染出来，就完成了组件的初始化。

那么问题来了，如果我希望在加载数据时给予用户以反馈，在加载时显示「数据正在加载中」这个提示，又该怎么做呢？

我们再加上一个 state，为 `isLoading` ，来指示列表是否正在加载中。如果加载中，那么显示加载动画和文字提示，且加载完以后显示列表，并取消加载状态。

那么我们的代码改写如下

```typescript
function BooksList() {
  const [listData,setListData] = useState([]);
  const [isLoading,setIsLoading] = useState(false);

  useEffect(()=>{
    setIsLoading(true)
    fetch('https://my-api.com/get-latest-books')
      .then((res)=>{
        setListData([...res.json()])
        setIsLoading(false)
      });
  },[])

  return (
    <>
    { isLoading ?
      <div>
        <LoadingAnimation/>
        <p>{"正在加载中"}</p>
      </div>
      :
      <ol>
        {listData.map((item,index) => (
          <li>
            <h2>{item.title}</h2>
            <p>{item.author}</p>
            <p>{item.price}</p>
          </li>)
        )}
      </ol>
    }
    </>
  )
}
```

在这里 fetch 和 setIsLoading 都是在组件挂载、渲染时的 effect。在这里，effect 提供了首次挂在组件时的状态、视图行为的指示，属于「加载的逻辑」。

### 伴随刷新组件状态

一个常用的场景就是分页查询。

比如，我有一个书籍列表页，简化如下：

```typescript

export default function BooksListPage() {

  const [listData,setListData] = useState([]);
  const [currentPage,setCurrentPage] = useState(1);

  const handleLoadListData = (pageNum:number) => {
    fetch(`https://my-api.com/books-list/${pageNum}`)
      .then((res)=>{
        setListData([...res.json()])
      })
  }

  useEffect(()=>{
    handleLoadListData(currentPage);
  },[])

  return (
    <main>
      <BooksList data={listData} />
      <p>{`现在是第 ${pageNum} 页`}</p>
      <button>
        {"上一页"}
      </button>
      <button>
        {"下一页"}
      </button>
    </main>
  )
}

```

以上写法是对 BooksList 列表的分页查询。我们放了一个 currentPage 来指示当前的页码。并且根据当前的页码 currentPage 来调用 API，加载对应的列表。现在，初始化组件的代码已经写好了，那么我们应该如何实现点击上一页、下一页按钮后，当前页码状态变化后，加载新页码对应的列表呢？

首先注意到：我们改变的是 currentPage 这个 State，而加载对应的列表则是受到 state 变化影响后的操作，加载对应的列表也同时修改了 listData 的 state。

实际上，加载对应列表就是一个 effect。

所以，我们可以设置一个 useEffect，加一个加载新页列表的 effect，这个 effect 的生效前提就是 currentPage 发生变化。

```typescript

export default function BooksListPage() {

  const [listData,setListData] = useState([]);
  const [currentPage,setCurrentPage] = useState(1);

  const handleLoadListData = (pageNum:number) => {
    fetch(`https://my-api.com/books-list/${pageNum}`)
      .then((res)=>{
        setListData([...res.json()])
      })
  }

  useEffect(()=>{
    handleLoadListData(currentPage);
  },[])

  useEffect(()=>{
    handleLoadListData(currentPage)
  },[currentPage])

  return (
    <main>
      <BooksList data={listData} />
      <p>{`现在是第 ${pageNum} 页`}</p>
      <button
        onClick={()=>setCurrentPage(currentPage - 1)}
      >
        {"上一页"}
      </button>
      <button
        onClick={()=>setCurrentPage(currentPage + 1)}
      >
        {"下一页"}
      </button>
    </main>
  )
}

```

这样当 currentPage 的 state 发生变化后，它会自动执行加载对应列表的 effect，这样就实现了组件的状态刷新。

### 缺陷

以上两类用途都有一个严格的前提：**effect 操作必须是幂等性操作**。幂等性，也就是说对于一个操作，初始操作和后续操作必须完全等效。

举个例子，在数据库操作中的增、查、删、改。我们查找数据库中的数据时，库中的数据并没有发生任何变化，我们第一次查询某个数据和后续多次查询这条数据，都不会对这个数据本身造成任何改动，既第一次操作和后续操作是完全等效的。所以查询数据就是一个幂等性操作。

但是我们要增、删、改数据时，被操作的数据就发生了变化：原先库中不存在的数据存在了，或者原先存在的数据不存在了，或者原先存在的数据被改动了一部分，都对数据库的总体数据添加了变化；这种操作就是非幂等性操作。

这也是 useEffect 的尴尬所在。

React 最初只是作为一种声明式构建、描述 UI 的库，它只重点关注输入数据流、状态数据流和输出 UI 三者之间的关系。它依赖输入→状态→输出这条单向链式数据流路线得到最终结果。

因为输入数据流是不确定的、随时的，也就导致状态也是不确定，再加上状态可以在组件内被业务逻辑随时更改，而状态的不确定性也就决定了 UI 渲染结果的不确定性。

> **注意：** 出于性能优化的原因，即使是 setState 操作更新 state 到最新数据后，React 也不一定会立即根据最新的 state 来渲染 UI，而是等待收集到足够多的最新 state 后批量更新、渲染。具体内容请了解官方文档。

所以 React 并不能准确确定组件什么时候会根据状态重新被刷新、渲染，也不能确定它会被刷新、渲染多少次。也就是说，你不能准确预料到某个操作后的下一步，组件是否会被刷新、重渲染。

所以，如果你把非幂等性操作作为 effect，那么就会导致数据与 UI 的不一致。

在 twitter, github 上，我常看到很多开发者抱怨 React 会在 debug 模式下，useEffect 中会执行两次 effect 操作而产生 BUG。实际上，他们是完全误解了 effect 的实际意义，误把 effect 当成 state 的事件监听器来使用。

只需要记住这条法则就能避免误用 effect :

> useEffect 的 Effect 只能用于幂等性的视图初始化、视图刷新，除此之外别无用途，更不应当用于任何业务逻辑。

虽然话说得很绝对，有一棒子打死的嫌疑，但是可以从根本上杜绝对 useEffect 误解而造成的滥用。

举一个例子，假如我们在在线商城的后台维护一个商品书目列表，对于「添加新书」的操作就不应当作为 effect。

```typescript
function BooksManager() {
  const [listData, setListData] = useState([]);

  const handleAddNewBook = (book) => {
    setListData((prevListData) => [book, ...prevListData]);
  };

  useEffect(() => {
    axios.post("https://my-api.com/add-book", {
      body: listData[0],
    });
  });

  // ....
}
```

以上代码有什么问题？

它试图在数据列表添加新项后马上同步提交到服务器，但是「添加新书」本身就不是一个幂等操作，这个 effect 不止会在 listData 的 state 改变后触发，也会在父组件重渲染后触发，触发次数也不确定。

那么，为这个 useEffect 加上依赖数组，限定只能在 listData 变化后触发，如何？

```typescript
useEffect(() => {
  axios.post("https://my-api.com/add-book", {
    body: listData[0],
  });
}, [listData]);
```

这么做是非常有风险的。

因为我一旦执行

```typescript
setListData([...listData]);
```

表数据本身没变，没有添加新书，根据 Diff 比较各个渲染节点也没变，但是状态数据中的数组引用变了，还是可能会触发 effect，会重复添加已有的书籍。

### 积重难返

上面说了那么多，接下来讲讲我的个人对 useEffect 的观点。很遗憾，useEffect 是非常失败的、无法挽回的错误。因 useEffect 造成的 bug、事故数不胜数。

传言 twitter 的网页端就曾发生过，twitter 程序员忘了给 useEffect 加上依赖数组，导致 useEffect 大量发送 GET 请求，以至于 twitter 的服务器直接崩溃。而且这种 Bug 事故原因一开始也没查出来，twitter 服务负载崩溃事件传到高层后，Elon Musk 以为是对手发动的网络爬虫攻击，于是给 twitter 设置了一天浏览量上限的乌龙事件。

因为它根植于 React 的底层核心设计思想，所以这种错误无法挽回。

我曾在知乎上看到过一个回答，很好地点出了问题所在：

> GUI 的本质是一个有生命周期的状态机，是状态数据、视图相互作用的结果，而不是单纯的 F(x)。

React 的 useEffect 写法确实很别扭，它从一开始就犯了很多根本性错误，由此衍生出的很多 hooks 优化手段不过是拆东补西。

比如状态的不确定性导致渲染的不确定性，有时会造成重复渲染浪费性能，就不得不用 `useMemo`、`useCallback`、`React.memo` 之类的方法来避免重复渲染，一切优化必须靠手动，徒增心智负担，导致 React 的性能在诸位框架中属于垫底的存在。

像 Vue 的框架就完全没有这个问题。Vue 的性能更是比 React 高出不少。

不过它是首批声明式前端 UI 框架，在这方面虽然走出了一些弯路，但经过多年实践，探索结果也未必没有意义。React 官方文档里也详细记录了很多坑，以及大大小小的修补方案。

虽然 React 这方面的坑比较多，但经过多年发展 React 仍然不失为一种优秀的前端框架。**在学习 React 时，对于这些「坑」应当吸取教训、避开这种写法，而不是在茴香豆的写法上钻牛角尖。**

正如同一位知友的总结：

> 下面很多人都提到了最关键的一点，不同步副作用中的状态不是 hooks 的标准做法，useEffect 更不是生命周期，不是 didUpdate. deps 只是受制于 JS 语言特性的无奈之举，并不是一种特性，所以任何业务不应该依赖于 deps 去实现。


文章讨论了在 React 中使用 useEffect 的挑战和陷阱，强调其在幂等视图初始化和刷新方面的正确应用，并警告不要进行非幂等操作，以避免数据和 UI 之间的不一致。

React 中的 useEffect 用途和一些坑


GraphQL is a query language for APIs proposed by Facebook. Many consider it as an alternative to REST, while others find GraphQL more complex than REST with no clear benefits. What unique capabilities does GraphQL have beyond the scope of REST? Is there an objective and rigorous criterion to help us make a judgment?

Nop Platform, through rigorous mathematical reasoning, has reinterpreted the positioning of GraphQL, resulting in new design ideas and technical implementation solutions. Under this interpretation, the NopGraphQL engine achieves comprehensive superiority over REST, strictly speaking, in the mathematical sense.

In simple terms, **GraphQL can be seen as an improvement of REST in a pull mode**, to some extent, it **reverses the flow of information**.

```text
query {
    NopAuthDept__findAll {
        name, status, children {name, status}
    }
}
```

Equivalent to `/r/NopAuthDept__findAll?@selection=name,status,children{name,status}`

Through **mathematical equivalence transformations (form transformations)**, we can clearly see that GraphQL is essentially supplementing a standardized `@selection` parameter to REST, allowing selective fetching of results.

Traditional REST is equivalent to pushing all information from the backend to the frontend, where the frontend cannot finely participate in the information production and transmission process. In the implementation of NopGraphQL, if the frontend does not request the `@selection` parameter, it automatically degrades to the traditional REST model, returning all non-lazy fields. Lazy fields need to be explicitly specified for them to be returned to the frontend.

In the architecture of Nop Platform, GraphQL is not just a transport protocol on par with REST; it is a **universal mechanism for information decomposition and composition**. It helps us organize the information structure of the system more effectively.

The positioning of NopGraphQL is as a general decomposition and dispatch mechanism for backend service functions. The same service function can be simultaneously published as a REST service, GraphQL service, gRPC service, Kafka message service, Batch processing service, etc. In simple terms, any scenario that involves receiving a Request Message and returning a Response Message can be directly integrated with the NopGraphQL engine as its implementation mechanism.

Using GraphQL has the following advantages compared to traditional REST:

## 1. Automatically trimming data loading scope based on requested data, achieving performance optimization

```text
@BizQuery
public PageBean<NopAuthUser> findPage(@Name("query") QueryBean query, FieldSelectionBean selection, IServiceContext context){
    PageBean<NopAuthUser> pageBean = new PageBean();
    if(selection != null && !selection.hasField("total")){
        long total = dao.countByQuery(query);
        pageBean.setTotal(total);
    }
    // ...
}
```

If the frontend does not require the total to be returned, the calculation of the total property can be skipped.

## 2. Automatic DTO adaptation by the engine, greatly enhancing the composability of data models

In traditional REST services, service functions directly return DTO objects, and all properties of DTO objects must be loaded in the service function. For example, if a virtual roles field is added to the NopAuthUser entity, it needs to be added to the DTO, and all places that return NopAuthUserDTO need to supplement the loading logic for the roles field. In NopGraphQL engine, the object returned by the service function is not directly serialized into JSON and returned to the frontend. Instead, it is processed further by the GraphQL engine using DataLoader to obtain the final returned data. This can significantly improve the composability of backend data models.

```java
@BizQuery
public List<NopAuthUser> findList(){
    // ...
}

@BizQuery
public NopAuthUser get(@Name("id") String id){
    // ...
}

@BizLoader
public List<String> roles(@ContextSource NopAuthUser user){
    // ...
}
```

In the example above, the findList and get functions only need to know how to load NopAuthUser objects, without needing to know how NopAuthUser is associated with NopAuthRole objects. Service functions can directly return entity objects without the need for manual translation into DTO objects. When we add a dynamic property roles to the NopAuthUser type through the `@BizLoader` mechanism, all places in the returned result that involve NopAuthUser automatically gain the roles property. The knowledge provided by DataLoader, through the action of the NopGraphQL engine, automatically combines with the functions we manually write, such as get/findList.

In NopGraphQL, we can also use an additional xmeta metamodel file to independently control the permissions, transformation, and validation logic of each field, simplifying and standardizing the implementation of service functions.

## 3. GraphQL's selection capability is a beneficial complement to the concept of aggregate roots in DDD

In Domain Driven Design (DDD), a critical and important design for information space planning is the concept of aggregate roots. Aggregate roots act as core nodes in the information space, allowing traversal in the information space by establishing direct connections with a few core nodes. Aggregates organize information in a form on the surface, reducing cognitive and usage costs, but it also has a negative impact on performance. GraphQL's selection capability is a complementary ability to the ability to aggregate (aggregation and selection as dual operations should be paired in design). It allows us to selectively extract slices of information we need from a vastly complex information structure, precisely meeting our business requirements.

## 4. GraphQL clearly distinguishes between query and mutation in terms of semantics, aligning more with the original intent of REST's Representational State Transfer design

Although REST specifies GET and POST methods, due to limitations at the implementation level (GET method does not support passing data through the HTTP body, URL length limitations, and security issues), we often cannot accurately differentiate the semantics of service functions through GET/POST. In the NopGraphQL framework, it is conventionally agreed that queries have no side effects and do not modify the database, while mutations have side effects and require consideration of transaction management, etc. Therefore, in the NopGraphQL framework, there is no need to manually add the `@Transactional` annotation for each service function; instead, a unified transaction environment is established for all mutation operations. Through optimizations at the implementation level, if a mutation does not actually access the database, the NopGraphQL framework does not actually obtain a database connection.

The NopGraphQL engine decomposes the execution of backend service functions into two phases: 1. Execute the service function, automatically establishing a transaction environment for mutations. 2. Process the result object returned by the service function, performing data transformation and pruning through DataLoader.

After the first phase is completed, the transaction is automatically closed, and some resource-consuming data loading tasks do not start executing. In the second phase, the transaction is closed, and the OrmSession is set to readonly. If entity data is inadvertently modified, an exception is automatically thrown. In this way, we can reduce the time the transaction is open and the time the database connection is occupied.


This article analyzes GraphQL's unique capabilities in API design, highlighting its advantages over REST, such as optimized data loading, enhanced data model composability, and improved semantic clarity in queries and mutations.

Why the Graphql Is Better than Restful in Math Conclusion?


_The Road to Serfdom_ is a work by Friedrich Hayek, published in 1944 with the full title "The Road to Serfdom: The Path to Individualism and Social Order." The book primarily explores the negative impact of collectivism and planned economies on individual freedom and social order.

**Key Points and Arguments:**

1. **Planned Economy Leads to Serfdom:** Hayek argues that excessive central planning and collectivist ideologies can result in political serfdom. He cautions that when governments attempt to excessively intervene in the economy and society, it may ultimately harm individual freedom, leading to a state of despotism.

2. **Free Market and Individualism:** The book advocates for free markets and individualism as effective means to ensure individual freedom and societal prosperity. Hayek believes that market mechanisms better satisfy people's needs, while excessive intervention distorts the market, leading to adverse consequences.

3. **Importance of Social Order:** The author contends that social order is not achieved through central planning but rather through the individual's free choices and market competition. Excessive concentration of governmental power may disrupt this order, causing chaos and instability.

In addition to the main points mentioned above, Friedrich Hayek presents several other significant ideas in _The Road to Serfdom_:

1. **Knowledge Problem of Planned Economies:** Hayek highlights the difficulty of central planning in effectively acquiring and utilizing dispersed knowledge within society. He argues that market mechanisms, through price systems, can transmit vast amounts of decentralized information, which central planning often fails to achieve.

2. **Individual Freedom and Social Responsibility:** The book emphasizes that individual freedom is not unlimited but exists within the framework of the rule of law. Hayek suggests that in a free society, individuals should bear some social responsibility for their actions to maintain overall social order.

3. **Defense of Liberalism:** _The Road to Serfdom_ serves as Hayek's defense of liberalism. He asserts that liberalism is not indifferent to societal issues but addresses them through the free choices of individuals and market competition while maintaining the rule of law and social order.

4. **Evolution of Social Rules:** The author stresses that the evolution of social rules should be a continuous process of adaptation to change, not dictated by central planning. He believes that the evolution of social rules occurs through the practical experiences of individuals, rather than through abstract theoretical planning.

These ideas collectively form the complex and profound liberal theory in "The Road to Serfdom," aiming to elucidate the relationship between free markets, individual freedom, and social order, as well as the potential negative consequences of central planning on these relationships.

**Methods of Argumentation:**

1. **Historical Case Analysis:** By analyzing the history of Nazi Germany and the Soviet Union, Hayek illustrates the relationship between planned economies and totalitarianism, aiming to demonstrate that planned economies may lead to the loss of individual freedom.

2. **Economic Theory and Market Principles:** The book employs economic and market principles to explain how market mechanisms, through supply and demand relationships and individual choices, efficiently allocate resources, positively impacting social order.

**Conclusion:**
The conclusion of _The Road to Serfdom_ is that to preserve individual freedom and social order, one should avoid excessive central planning and collectivist ideologies. Individualism and free-market mechanisms are considered key factors in constructing a robust social order.

In summary, Hayek presents a critique of planned economies and collectivism in this book, emphasizing the importance of individual freedom and market mechanisms for society. This has established _The Road to Serfdom_ as a classic in 20th-century liberal thought.


The Road to Serfdom by Friedrich Hayek warns against planned economies, advocating for free markets and individualism to safeguard freedom and societal order. Hayek critiques central planning, emphasizing the knowledge problem and the evolution of social rules, defending liberalism as a solution.

Viewpoints and Conclusions of The Road to Serfdom


Kamil Galeev presents a fascinating perspective. He observes that, similar to how certain gangs in Mexico control the avocado industry, criminal organizations worldwide tend to dominate sectors like drugs, fruit, minerals, and even entertainment. However, he poses an intriguing question: have we ever seen gangs controlling high-tech industries? Galeev explains that this absence is due to the relative simplicity of power structures within gang organizations.

He suggests a trend in the relationship between gangs and various industries, where gangs prefer to venture into fields that are operationally simpler. For instance, if a gang were to enter the mechanical production sector, they would face two likely outcomes. One, they would be unable to adapt and ultimately fail, as the complexity of mechanical production exceeds their simple power structure's managerial capabilities. Alternatively, they would need to delegate authority to professionals, transforming from a gang into more of a business entity, with actual power swiftly shifting into the hands of knowledgeable individuals.

Galeev interprets this phenomenon as stemming from the simplicity in the operation of gang power. He likens this to the simplicity of totalitarian politics compared to democratic systems, which partly explains his lack of interest in analyzing totalitarian politics. In his view, gangs gravitate towards simpler industries because power is more directly and effectively exercised in these areas.

However, the situation becomes complicated when gangs attempt to infiltrate more complex industries. In such sectors, the dependence on knowledge and specialized skills becomes paramount. Galeev notes that this high dependency on knowledge poses a dilemma for gangs, as their simple power structures are ill-equipped to manage such complexity. Complex industries require professional management and technical expertise, areas where gangs typically lack proficiency.

This also raises a point for reflection about the adaptability of different organizational forms in society. Gangs succeed in industries like drugs and fruits because these sectors are relatively straightforward and can be operated through more basic methods. However, when faced with complex domains like high-tech industries, the simplistic modus operandi of gangs clearly falls short. In contrast, formal businesses and organizations are more likely to thrive in complex industries due to their focus on specialization, innovation, and efficient management.

Therefore, Galeev's insights not only offer an intriguing view into the activities of criminal organizations but also provoke deeper contemplation on organizational forms, power structures, and the management of complex industries. The evolution of society and the development of industries reveal different strengths and weaknesses in various organizational types, presenting a rich area for exploration in organizational studies and social sciences.


Galeev: Gangs excel in simple industries, struggle in complex sectors.

Why Can't the Underworld Manage High Technology?


Event handlers are fundamentally callback functions, wherein the calling privilege is relinquished to the event initiator, and the program responsible for the event is automatically invoked when the event occurs. Regarding the source of events, it depends on the perspective. From a process standpoint, a small portion of events is indeed obtained through polling, while the majority is processed through a message loop structure. A message loop typically monopolizes a thread and can be expressed in pseudocode as follows:

```pseudo
while (true) {
  if(GetEvent()) {
    ProcessEvent()
  }
  continue;
}
```

This represents a loop that retrieves an event and processes it. Handling events usually involves calling event handler functions. So, how are events obtained? Aside from polling, it is often accomplished with the assistance of the operating system. The operating system provides certain blocking calls, such as `select`, `epoll`, and Windows' `GetMessage`, `WaitForMultipleObjects`, etc. These blocking calls generally handle multiple signal sources, returning when any of them undergoes a change, allowing the simultaneous tracking of various inputs.

In addition to event loops, another design involves the operating system directly triggering specific callback functions. Typical examples include Linux's `signal`, `aio`, Windows' `SendMessageWithCallback`, etc. Such callbacks typically interrupt the ongoing system call immediately. This integration of callbacks with event loops involves setting flags during the callback process, checking these flags when the blocking concludes, thereby seamlessly incorporating these callbacks into the usual event loop.

Now, from the perspective of the operating system, the kernel can arbitrarily schedule user processes. When a user process makes a system call, transitioning to kernel mode, the kernel suspends the current process. Upon the occurrence of the corresponding event, the kernel then awakens the respective user process, allowing it to resume execution. Thus, the kernel essentially functions as an event callback system.

Delving deeper, where do the events in the kernel come from? A crucial mechanism is known as interrupts, which, in simple terms, are hardware-implemented signal handlers. CPUs typically execute instructions sequentially, with the kernel sequentially executing user programs. In instances where all user processes are suspended, the kernel executes an idle process, engaging in a loop executing low-power instructions. A notable exception is interrupts. CPUs possess interrupt pins, and a change in voltage on these pins immediately initiates the interrupt process. The hardware structure within the CPU promptly enters kernel mode, reads the interrupt vector table, and then jumps to the corresponding code based on the address in the table for execution.

Interrupt handling procedures usually begin by saving the context, querying information from hardware sharing the interrupt, saving it to specific data structures, resetting the interrupt, and then promptly returning to kernel mode. The kernel subsequently queries interrupt information and executes specialized handling procedures. These procedures ultimately restore the execution of user-space programs, and the cycle repeats.

In essence, this is a counterpart to signal handlers and event loops in user space. Apart from hardware interrupts, there are interrupts triggered internally by the CPU. A crucial example is the timer interrupt, and the handling process is identical. Some hardware employs timer interrupts for polling, such as USB. In summary, hardware notifies the kernel through interrupts, the kernel informs user processes (threads) through blocking calls and event handlers, and the user framework manages notifications, triggering event handlers.


This article explores the essence of event handlers as callback functions, relinquishing control to event initiators. Events are obtained through either polling or operating system-assisted methods like blocking calls. The operating system serves as an event callback system, handling interrupts, and integrating callbacks into event loops.

The Event-Listening Implementation


## Equals

```typescript
type Equals<T, U> = T extends U ? (U extends T ? true : false) : false;

type Type1 = { a: number; b: string };
type Type2 = { a: number; b: string };
type Type3 = { a: number; c: string };

type Test1 = Equals<Type1, Type2>; // true
type Test2 = Equals<Type1, Type3>; // false
```

## If

```typescript
type If<C extends boolean, T, F> = C extends true ? T : F;

type A = If<true, "a", "b">; // expected to be 'a'
type B = If<false, "a", "b">; // expected to be 'b'
```

## Includes

```typescript
type Includes<T extends any[], U> = {
  [K in T[number]]: true;
}[U] extends true
  ? true
  : false;

type MyType = Includes<["Kars", "Esidisi", "Wamuu", "Santana"], "Dio">;
// expected to be `false`
```

## Merge

```typescript
type Merge<T> = {
  [P in keyof T]: T[P];
};
```

## Diff

```typescript
type Diff<O, O1> = Merge<
  {
    [P in Exclude<keyof O, keyof O1>]: O[P];
  } & {
    [P in Exclude<keyof O1, keyof O>]: O1[P];
  }
>;
```

## Ranged Number

```typescript
type IsMore<A extends number, B extends number, L extends any[] = []> = A extends L["length"]
  ? false
  : B extends L["length"]
    ? true
    : IsMore<A, B, [...L, any]>;
type NumRange<Max, Min> = isMore<infer U, Min> extends true ? (isMore<Max, U> extends true ? U : never) : never;

type MyType = NumRange<1000, 9999>;
// Only number 1000-9999 can be accepted.
```

## Tuple To Union

```typescript
type TupleToUnion<T extends any[]> = T[number];

type Arr = ["1", "2", "3"];
const test: TupleToUnion<Arr>; // expected to be '1' | '2' | '3'
```

## String To Union

```typescript
type StringToUnion<T extends string> = T extends `${infer First}${infer Reset}` ? First | StringToUnion<Reset> : never;
type Test = "123";
type Result = StringToUnion<Test>; // expected to be "1" | "2" | "3"
```

## Length of String

```typescript
type LengthOfString<S extends string, T extends any[] = []> = S extends `${infer L}${infer R}`
  ? LengthOfString<R, [...T, L]>
  : T["length"];

type MyType = LengthOfString<"hello">; // 5
```


TypeScript Type-Exercises-3


## Spilt String into Chars

```ts
type Split<T extends string, U extends unknown[] = []> = T extends `${infer F}${infer Rest}`
  ? Split<Rest, [...U, F]>
  : U;

type MyType = Split<"abcdef">;
// MyType = ["a", "b", "c", "d", "e", "f"]
```

## Trim, TrimStart, TrimEnd

```ts
type TWhiteSpace = " " | "\n" | "\t";

type TrimStart<S extends string> = S extends `${TWhiteSpace}${infer R}` ? TrimStart<R> : S;
type TrimEnd<S extends string> = S extends `${infer R}${TWhiteSpace}` ? TrimEnd<R> : S;
type Trim<T extends string> = TrimRight<TrimLeft<T>>;

type MyTrimEnd = TrimEnd<"Hello World   ">;
// 'Hello World'
type MyTrimStart = TrimStart<"  Hello World">;
// 'Hello World'
type MyTrim = Trim<"   Hello World   ">;
// 'Hello World'
```

## Lowercase To Uppercase

```ts
type LowercaseToUppercase<L extends string> = L extends `${"a"}${infer R}`
  ? `${"A"}${LowercaseToUppercase<R>}`
  : L extends `${"b"}${infer R}`
  ? `${"B"}${LowercaseToUppercase<R>}`
  : L extends `${"c"}${infer R}`
  ? `${"C"}${LowercaseToUppercase<R>}`
  : L extends `${"d"}${infer R}`
  ? `${"D"}${LowercaseToUppercase<R>}`
  : L extends `${"e"}${infer R}`
  : .....
  : L;

type MyUppercase = LowercaseToUppercase<"hello">;
// MyUppercase = "HELLO"
```

With the akin method, we also make a `UppercaseToLowercase` type definition.

## Capitalize

```ts
type Capitalize<S extends string> = S extends `${infer L}${infer R}` ? `${Uppercase<L>}${R}` : "";

type MyType = Capitalize<"hello world">;
// MyType = 'Hello world'
```

## Replace

```ts
type Replace<S extends string, F extends string, T extends string> = F extends ""
  ? S
  : S extends `${infer L}${F}${infer R}`
    ? `${L}${T}${R}`
    : S;

type MyType = Replace<"this is the test demo", "e", "E">;
// MyType: 'this is thE test demo'
```

It replace the first matched char.

## Replace All

```ts
type ReplaceAll<S extends string, F extends string, T extends string> = F extends ""
  ? S
  : S extends `${infer L}${F}${infer R}`
    ? `${ReplaceAll<L, F, T>}${T}${ReplaceAll<R, F, T>}`
    : S;

type MyType = ReplaceAll<"this is the test demo", "e", "E">;
// MyType: 'this is thE tEst dEmo'
```

Replace all matched chars.

## StartsWith && EndsWith

```ts
type StartsWith<T extends string, U extends string> = T extends `${U}${string}` ? true : false;
type EndsWith<T extends string, U extends string> = T extends `${string}${U}` ? true : false;

type a = StartsWith<"abc", "ac">; // false
type b = StartsWith<"abc", "ab">; // true
type c = StartsWith<"abc", "abcd">; // false
```

## Repeat String

```ts
type RepeatString<
  Input extends string,
  Count,
  AuxArr extends Input[] = [],
  Result extends string = "",
> = AuxArr["length"] extends Count ? Result : RepeatString<Input, Count, [Input, ...AuxArr], `${Input}${Result}`>;

type MyType = RepeatString<"hello", 3>;
// 'hellohellohello'
```


There are some type exercise about string literal type.

TypeScript Type-Exercises 2


- Template String

```ts
type URL:`https://${string}:${port}`
let a1:URL = 'https://google.com:443' // ok
let a2:URL = 'https://test' // error
```

## Get the return type of the function

```ts
type ReturnType<T> = T extends (...args: any[]) => infer R ? R : any;

type T2 = ReturnType<() => string>; // T2 = string
const sum = (a: number, b: number): number => a + b;
type T3 = ReturnType<sum>; // T3 = number
```

## Get the parameters type list

```ts
type Parameters<T extends (...args: any[]) => any> = T extends (...args: infer P) => any ? P : never;

type Func = (a: number, b: string) => void;
type Params = Parameters<Func>;
// Params = [number, string]
```

**Note:** For above two examples they showed the keyword `infer`'s usage. \
Namely you can treat them as a variable that contain the correspond type. \
For example, in `type Parameters<T extends (...args: any[]) => any> = T extends (...args: infer P) => any ? P : never` , the `infer P` means storing the types of `...args` into `P` and assigns `P`'s value to the `Parameters` if `T` is an function.

## Restrict the variable equals to one of the elements in an Tuple

```ts
const myTuple = ["a", 100, false] as const;

type MyType = (typeof myTuple)[number];

let myVar: MyType;
// myVar could only be 'a', 100 or false
```

**Note:** In this example the `myTuple` was perceived an readonly tuple and every element are its literal type, namely the first element is the `'a'` type rather then `string`. If you want to make `MyType = string | number | boolean` you can remove the `as const` assertion.

## Equal to the first element in a specified tuple.

```ts
type First<T extends any[]> = T extends [infer F, ...infer R] ? F : never;

type MyType = First<["a", 100, false]>;
// MyType = 'a'
```

## Awaited. Get the type `T` of `Promise<T>`

```ts
type Awaited<T extends Promise<any>> = T extends PromiseLike<infer L> ? L : never;

const asyncFunc = async () => {
  return true;
};
type MyType = Awaited<asyncFunc>;
// MyType = boolean.
```


TypeScript Type-Exercises 1


![蔡元培（1868-1940），字鹤卿](https://image-assets.dreams.plus/7b2044bab6ac61e0b9dfc6ebcdcf620.webp)

五年前，严几道先生为本校校长时，余方服务教育部，开学日曾有所贡献于学校。诸君多自预科毕业而来，想必闻知。士别三日，刮目相见，况时阅数载，诸君较昔当为长足之进步矣。予今长斯校，请以三事为诸君告：

一曰抱定宗旨。诸君来此求学，必有一定宗旨，欲求宗旨之正大与否，必先知大学之性质。今人肄业专门学校，学成任事，此固势所必然。而在大学则不然，大学者，研究高深学问者也。外人每指摘本校之腐败，以求学于此者，皆有做官发财思想，故毕业预科者，多入法科，入文科者甚少，入理科者尤少，盖以法科为干禄之终南捷径也。因做官心热，对于教员，则不问其学问之浅深，惟问其官阶之大小。官阶大者，特别欢迎，盖为将来毕业有人提携也。现在我国精于政法者，多入政界，专任教授者甚少，故聘请教员，不得不聘请兼职之人，亦属不得已之举。究之外人指摘之当否，姑不具论，然弭谤莫如自修，人讥我腐败，问心无愧，于我何惧？果欲达其做官发财之目的，则北京不少专门学校，入法科者尽可肄业于法律学堂，入商科者亦可投考商业学校，又何必来此大学？所以诸君须抱定宗旨，为求学而来，入法科者，非为做官;入商科者，非为致富。宗旨既定，自趋正轨，诸君肄业于此，或三年，或四年，时间不为不多，苟能爱惜分阴，孜孜求学，则求造诣，容有底止。若徒志在做官发财，宗旨既乖，趋向自异。平时则放荡冶游，考试则熟读讲义，不问学问之有无，惟争分数之多寡;试验既终，书籍束之高阁，毫不过问，敷衍三、四年，潦草塞责，文凭到手，即可借此活动于社会，岂非与求学初衷大相背驰乎？光阴虚度，学问毫无，是自误也。且辛亥之役，吾人之所以革命，因清廷官吏之腐败。即在今日，吾人对于当轴多不满意，亦以其道德沦丧。今诸君苟不于此时植其基，勤其学，则将来万一因生计所迫，出而仕事，但任讲席，则必贻误学生;置身政界，则必贻误国家。是误人也。误已误人，又岂本心所愿乎？故宗旨不可以不正大。此余所希望于诸君者一也。

二曰砥砺德行。方今风俗日偷，道德沦丧，北京社会，尤为恶劣，败德毁行之事，触目皆是，非根基深固，鲜不为流俗所染。诸君肄业大学，当能束身自爱。然国家之兴替，视风俗之厚薄。流俗如此，前途何堪设想。故必有卓绝之士，以身作则，力矫颓俗，诸君为大学学生，地位甚高，肩此重任，责无旁贷，故诸君不惟思所以感已，更必有以励人。苟德之不修，学之不讲，同乎流俗，合乎污世，已且为人轻侮，更何足以感人。然诸君终日伏首案前，芸芸攻苦，毫无娱乐之事，必感身体上之苦痛。为诸君计，莫如以正当之娱乐，易不正当之娱乐，庶几道德无亏，而于身体有益。诸君入分科时，曾填写愿书，遵守本校规则，苟中道而违之，岂非与原始之意相反乎？故品行不可以不谨严。此余所希望于诸君者二也。

三曰敬爱师友。教员之教授，职员之任务，皆以图诸君求学便利，诸君能无动于衷乎？自应以诚相待，敬礼有加。至于同学共处一室，尤应互相亲爱，庶可收切磋之效。不惟开诚布公，更宜道义相勖，盖同处此校，毁誉共之。同学中苟道德有亏，行有不正，为社会所訾詈，已虽规行矩步，亦莫能辨，此所以必互相劝勉也。余在德国，每至店肆购买物品，店主殷勤款待，付价接物，互相称谢，此虽小节，然亦交际所必需，常人如此，况堂堂大学生乎？对于师友之敬爱，此余所希望于诸君者三也。

余到校视事仅数日，校事多未详悉，兹所计划者二事：一曰改良讲义。诸君既研究高深学问，自与中学、高等不同，不惟恃教员讲授，尤赖一已潜修。以后所印讲义，只列纲要，细微末节，以及精旨奥义，或讲师口授，或自行参考，以期学有心得，能裨实用二曰添购书籍。本校图书馆书籍虽多，新出者甚少，苟不广为购办，必不足供学生之参考。刻拟筹集款项，多购新书，将来典籍满架，自可旁稽博采，无虞缺乏矣。今日所与诸君陈说者只此，以后会晤日长，随时再为商榷可也。


《就任北京大学校长之演说》是近代教育家蔡元培的演说作品，是蔡元培在 1917 年就任北京大学校长时发表的。这篇就任北京大学校长的就职演讲，开宗明义地对青年学子提出了三点要求：一是抱定宗旨；二是砥砺德行；三是敬爱师友。明确求学目的及办学宗旨，望学子们以身作则，匡正流俗，为天下人之道德楷模。

MY BLOG

ALL POSTS