We know that after Reactits release Hooks, it brought a wave of Hooksenthusiasm in the industry. Many frameworks (such as Vue Composition API, Solid.js) have borrowed Hookspatterns from .

However, even if these frameworks are borrowed from each other Hooks, the development directions are gradually different due to the different ideas of the framework authors.

For example, in Vue Composition API, the React useEffect APIbenchmark is that watchEffectin Vuethe document, there is a short paragraph introducing its usage:

In React betathe document, useEffectit is introduced in 6 sections:

Why is there such a difference? Let’s start by useEffecttaking a look Reactat Vuethe differences in design concepts.

Welcome to join the human high-quality front-end framework group and lead the team

Differences between Vue and React

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

The useEffectexecution timing includes the following three life cycle functions:

• componentDidMount
• componentDidUpdate
• componentWillUnmount

On the other Hookshand Vue Composition API, it also provides watchEffect APIlife cycle functions for different scenarios.

The difference in design concepts between the two is already reflected here:

ReactAs a framework created Facebookto explore best practices in UI development , the consistent approach is to remain APIstable (for example, it has existed this.setStatesince its inception).React

Instead, Vueit draws on best practices from various frameworks (such as 虚拟DOM… 响应式更新).

Therefore, in terms of ease of use, Vue Composition APIit is definitely better React Hooks, such as:

• Hookscannot be declared in a conditional statement
• HooksDependencies must be explicitly specified

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 maintaining API stability , it is currently useEffectmainly related to the above three life cycle functions.

However, there will be more triggering opportunities and useEffecthooks in the future.

Therefore, Reactthe team is trying to do one thing – downplay useEffectthe relationship with the life cycle, and even downplay useEffectthe relationship with the components (because when talking about components, it is natural to think of the component life cycle).

How to dilute it? The answer is – in strict mode, DEVthe environment will trigger multiple useEffectcallbacks.

If you use useEffectit componentDidMount/WillUnmount, this feature is likely to make your code break bug.

ReactThe reason why the team does this is to educate developers – useEffectit has nothing to do with the life cycle. Developers should useEffectthink of this as a synchronization process against a data source .

For example, the following chat room component useEffectcan 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 component mount, update, unmountthe corresponding synchronization process should be carried out.

When roomIdchanges occur, the corresponding synchronization process should be performed.

In the same way, if Reactit is natively supported , the synchronization process should be carried out when the chat room component changes from visible to invisible , and from invisible to visible .VueKeepAlive

So, when we look at it from the perspective of when the synchronization process should take placeuseEffect , the above useEffecttrigger timings are all reasonable.

However, if you look at it from the perspective of life cycle functions , when the features are implemented in useEffectthe future (maybe a certain version of v18) and the components change from visible to invisible , they will be executed in sequence, which will cause People have big heads.Offscreen ComponentVueKeepAliveuseEffect销毁函数useEffect回调函数

This is why, as I said above, Reactthe team has been downplaying useEffectthe relationship with the life cycle, and even downplaying useEffectthe relationship with components.

Everything is to lay a theoretical foundation for linking other features with useEffect in the future . These features don’t make sense from the perspective of components or lifecycle functions .

useEffectThis is why there are 6 relevant sections in the new document .

As a comparison, Vuewhat do you do when you encounter a new scene? Apparently new by design API.

Summarize

Is it better to provide one APIthat can cover more scenarios (the document has 6 sections to introduce it), or is it better to provide one for every scenario API?

Different developers have their own answers.

But one thing is clear, for front-end novices, Reactit will become more and more difficult to get started, while Vuethe difficulty of getting started will be kept as smooth as possible.

The front-end novices here may be new people who want to get into the front-end industry, or they may be back-end people who feel that I can also do the front-end .

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