The difference between React and Vue design concepts from useEffect

Hello everyone, I'm Casson.

We know that after the release of React Hooks , it brought a wave of Hooks in the industry. Many frameworks (such as Vue Composition API , Solid.js ) borrow the pattern of Hooks .

However, even though these frameworks borrow from Hooks , the development direction is gradually different due to the different ideas of the framework authors.

比如， Vue Composition API中，对标React useEffect API的是watchEffect ， Vue文档中，有一小段内容介绍他的用法：

In the React beta document, which introduces useEffect , there are 6 full sections:

Why is there such a difference? Let's take a look at the difference in design philosophy from useEffect React and Vue .

Welcome to join the human high-quality front-end framework group , with flying

Differences between Vue and React

When Hooks first came out, it was seen as an alternative to class components. In the document Hooks is also compared with class components.

Among them, the execution timing of useEffect includes the following three life cycle functions:

• componentDidMount
• componentDidUpdate
• componentWillUnmount

In contrast, Hooks of Vue Composition API is used for reference, and watchEffect API and life cycle functions of different scenarios are also provided.

Here is the difference between the two design concepts:

React作为---35d11fa39a903e9545cd6b5293c06851 Facebook探索UI开发最佳实践而生的框架， API （ this.setState has been around since the beginning of React ).

And Vue borrows best practices from various frameworks (eg 虚拟DOM , 响应式更新 ...).

Therefore, in terms of ease of use, Vue Composition API is definitely better than React Hooks , for example:

• Hooks Cannot declare in conditional statement
• Hooks dependency must be specified explicitly

Moreover, this difference in ease of use will become more and more obvious as the framework iterates.

useEffect will become more and more complex

In line with the principle of keeping the API stable , the current useEffect is mainly related to the above three life cycle functions.

However, there will be more trigger timings linked to useEffect in the future.

So, React the team is trying to do one thing -- downplaying the useEffect relationship with the lifecycle, and even downplaying the useEffect relationship with the component (because when it comes to components, the component life cycle comes naturally).

How to dilute it? The answer is -- in strict mode, the DEV environment triggers multiple useEffect callbacks.

If you use useEffect as componentDidMount/WillUnmount , this feature will likely make your code bug .

React reason why the team did this is to educate developers useEffect has nothing to do with the life cycle. Developers should think of useEffect as a synchronization process for a data source .

For example, the following chat room component, in which useEffect can be regarded as the synchronization process for the chat room connection :

 const serverUrl = 'https://localhost:1234';

function ChatRoom({ roomId }) {
  useEffect(() => {
    const connection = createConnection(serverUrl, roomId);
    connection.connect();
    return () => {
      connection.disconnect();
    };
  }, [roomId]);
  // ...
}

When the chat room components mount , update , unmount , the corresponding synchronization process should be performed.

When roomId changes, the corresponding synchronization process should be carried out.

Similarly, if React natively supports Vue in KeepAlive , then when the chat room component changes from visible to invisible , and from invisible to visible state, the synchronization process should all proceed.

Therefore, when we look at when the synchronization process should take place useEffect , the above-mentioned useEffect trigger timing is reasonable.

However, if you look at it from the perspective of life cycle functions useEffect , and wait for the future (maybe a version of v18), Offscreen Component features landed (the benchmark Vue in KeepAlive ), when the component changes from visible to invisible state, useEffect销毁函数 and useEffect回调函数 will be executed in sequence, which will make people very big.

That's why, as I said above, the React team has been downplaying the useEffect relationship with the lifecycle, and even downplaying the useEffect relationship with the component.

Everything is to lay a theoretical foundation for hooking other features to useEffect in the future . And these features don't make sense from the perspective of components or lifecycle functions .

This is why there are 6 sections in the new document related to useEffect .

As a comparison, Vue what would you do when encountering a new scene? Apparently new by design API .

Summarize

Is it good to provide one API , but it can cover more scenarios (the document has 6 sections to introduce him), or is it good to provide one for each scenario API ?

Different developers have their own answers.

But one thing is clear, for front-end novice, React will become more and more difficult to get started, while Vue will be as smooth as possible.

The front-end novice here may be a newcomer who wants to enter the front-end, or it may be a back-end who thinks that I can do the front -end.

So, is this a good thing or a bad thing for current practitioners?