
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 用途和一些坑


**I have a suggestion: When you are entangled in whether to use a certain technology, first check what level the technology solves and what problems, and then examine whether you need to solve such problems. Can save unnecessary entanglement.**

So what problem does WebSocket solve? The session management in the traditional HTTP protocol is not perfect. The client must actively initiate a Request request before the server can deliver messages to the client.

If the client submits a time-consuming task to the server, how does the server send a message to the client after it is done? In other words, in some scenarios, the server must ensure that the client is online. The solution is AJAX polling or alive detection. The client sets a timer, and every once in a while the client will initiate an AJAX request to the server, asking whether the server has completed the task, or actively telling the server "I am still online", so as to obtain the data returned by the server in time.

AJAX polling is still useful if there are fewer clients and the server performance is strong enough, but if there are more clients, what if the server has to accept requests from tens of thousands of clients? Not to mention taking up bandwidth, can the server withstand these pressures? If the real-time requirements are high, it means that resources are updated frequently and the amount of data transmitted is large, such as games and web conferences, and the method of conveying messages through AJAX polling cannot be used.

**WebSocket solves the two problems mentioned above: it makes up for the defect that the server cannot actively contact the client, and jointly solves the pressure brought by the traditional one-way communication on the server. Another is to solve the problem of real-time communication**

The client and the server only need to complete a handshake, and a persistent connection can be created directly between the two, and two-way data transmission can be performed. In this way, even if there is no explicit request from the client, the server can send information to the client, realizing reverse communication.

Although WebSocket also has a certain performance consumption, it is still very cost-effective compared to the consumption of large-scale AJAX polling.

If your business scenario needs to solve the above two problems, then it is recommended to use it, otherwise it is unnecessary, depending on your understanding of the business.


Should Put All Requests in a Websocket Connection?


## React.memo

React.memo is a **component level** cache API in React, which can temporarily store rendered components, and when necessary, decide whether to update the rendering or obtain it directly from the cache to avoid unnecessary component rendering.

And its' usage:

```javascript
const MyMemoedComponent = React.memo(
  function MyComponent(props) {
    /* render with props */
  },
  function compare(prevProps, currentProps) {
    /* logics for comparing the prevProps and nextProps */
  },
);
```

It returns a Memorized function component.

When used, it accepts two parameters: the first is the target component, which is the definition of the component that needs to be optimized.
The second is the comparison function `compare`, which receives the currentProps passed in for each round of rendering and the prevProps passed in for the last rendering.

However, due to the immutable feature in the React function component, the component will be rendered according to its Props. However, when the same or equivalent Props are used multiple times during rendering, performance will be wasted.

Users can write their own logic to determine whether the two incoming props are logically equivalent. The `compare` function is expected to return a boolean value. If it returns `true`, it means that the props passed in twice are equivalent. Then during the current round of rendering, the last component will be directly taken out of the cache without re-rendering the component.

For example, when it is necessary to render a personal resume information, if the personal information on the resume remains unchanged, then there is no need to re-render. Can be used like this:

```javascript
const MyMemoedProfile = React.memo(
  function Profile({ name, sex, age, job }) {
    return (
      <div>
        <h2>{`Your Name: ${name}`}</h2>
        <ul>
          <li>{`sex: ${sex}`}</li>
          <li>{`age: ${age}`}</li>
          <li>{`job: ${job}`}</li>
        </ul>
      </div>
    );
  },
  function compare(prevProps, currentProps) {
    return (
      prevProps.name === currentProps.name &&
      prevProps.sex === currentProps.sex &&
      prevProps.age === currentProps.age &&
      prevProps.job === currentProps.job
    );
  },
);
```

## useMemo

The `React.memo` mentioned above is the optimization of the component level, **then useMemo is the optimization of the internal calculation logic of the component.**

JavaScript is not suitable for intensive calculations. But if we have calculation-intensive logic inside the component, every time the component is rendered, the calculation must be done again, which is also unacceptable for performance. Therefore, useMemo can temporarily store the intensive calculation results of each time, and then decide whether to repeat the calculation according to the judgment.

The specific usage is as follows:

```javascript
const memoizedValue = useMemo(() => doSomeComputeExpensiveWork(a, b, ...), [a, b, ...]);
```

Unlike React.memo, its first parameter is a function that returns a computationally intensive function. It accepts dependencies instead of comparison functions as its second argument. Dependencies will be compared (shallow comparison here) every time a value is fetched. If the dependencies are the same, the last rendering result will be reused instead of recalculated. If the dependencies are different, call the computationally intensive function returned by the first argument.

For example, we want to design a component that displays the Fibonacci sequence: input the number of items `n`, and return the Fibonacci number of the `n`th item.

```javascript
function FibonacciNumber({ n }) {
  const target_value = useMemo(
    () =>
      function calc(n) {
        let arr = [];
        if (n < 1) return arr;
        let one = 1,
          two = 0,
          three = 0;
        for (let i = 1; i <= n; i++) {
          three = one + two;
          arr.push(three);
          one = two;
          two = three;
        }
        return arr;
      },
    [n],
  );
  return <div>{`The ${n} th's fibonacci number is : ${target_value}`}</div>;
}
```

In this way, no matter how many rounds the component renders, as long as the dependency `n` remains unchanged, the previously calculated Fibonacci numbers will be obtained from the cache instead of recalculated. If a new `n` is obtained, the `calc` function returned by the first parameter will be used again to calculate the new value with `n` as the parameter.

If the dependency is empty, the data is always fetched from the cache.

## useCallback

useMemo has a problem: the function in the first argument must return a computationally intensive function. If the first parameter is directly set to a calculation-intensive function, it will be simplified a lot, as long as the calculation-intensive function does not need to be changed.

useCallback can be regarded as the equivalent grammatical sugar of useMemo, and there is the following conversion relationship between them:

`useCallback(fn, deps)` is equivalent to `useMemo(() => fn, deps)`.

Like useMemo, if the dependency is empty, the data is always fetched from the cache.

## useEvent

Try the following code:

```javascript
const MyComponent = () => {
  const [counter, setCounter] = useState(0);

  const handleClick = () => {
    console.log(counter);
    setCounter((counter) => counter + 1);
  };

  return <div onClick={handleClick}>click to add counter counter: {counter}</div>;
};
```

There seems to be no problem with this component, but if you think about it carefully, a new `handlerClick` event function will be recreated every time it is rendered and then passed to the button. So if the component is rendered many times, the handlers established in history will accumulate more and more.

In order to solve this problem, we put a layer of useCallback to cache the event forever, and always get data from the cache in each round of rendering:

```javascript
const MyComponent = () => {
  const [counter, setCounter] = useState(0);

  const handleClick = useCallback(() => {
    console.log(counter);
    setCounter((counter) => counter + 1);
  }, []);

  return <div onClick={handleClick}>click to add counter counter: {counter}</div>;
};
```

But this triggers React's closure trap. The `counter` in the function in the first parameter is always the value when the component is first created, that is `0`.

So useEvent solves the problem:

```javascript
const MyComponent = () => {
  const [counter, setCounter] = useState(0);

  const handleClick = useEvent(() => {
    console.log(counter);
    setCounter((counter) => counter + 1);
  });

  return <div onClick={handleClick}>click to add counter counter: {counter}</div>;
};
```

But it is still an experimental feature today and not recommended for production use.


NOTE & BLOG

Posts of REACT

The Usages and Traps of useEffect in React

React 中的 useEffect 用途和一些坑

Should Put All Requests in a Websocket Connection?

Optimization Scheme for React Component Rendering