useEffect理解React、Vue設計理念的不同

2022-09-20 22:01:39

引言

我們知道，React釋出Hooks後，帶來了業界一波Hooks熱。很多框架（比如Vue Composition API、Solid.js）都借鑑了Hooks的模式。

但是，即使這些框架都借鑑了Hooks，但由於框架作者的理念不同，發展方向也逐漸不同。

比如，在Vue Composition API中，對標React useEffect API的是watchEffect，在Vue檔案中，有一小段內容介紹他的用法：

而在React beta檔案中，介紹useEffect的，則有整整6節內容：

為什麼會有這樣的區別？讓我們從useEffect看看React、Vue設計理念的不同。

Vue與React的差異

當Hooks剛問世時，他被看作是類元件的替代方案。檔案中介紹Hooks時也是將他與類元件對比。

其中useEffect的執行時機囊括瞭如下3個生命週期函數：

componentDidMount

componentDidUpdate

componentWillUnmount

反觀借鑑了Hooks的Vue Composition API，則同時提供了watchEffect API與不同場景的生命週期函數。

這裡已經體現出兩者設計理念的不同了：

React作為Facebook為探索UI開發最佳實踐而生的框架，一貫的做法是 —— 保持API穩定（比如this.setState從React誕生伊始就一直存在）。

而Vue則借鑑了各種框架中的最佳實踐（比如虛擬DOM、響應式更新...）。

所以，從易用性上來說，Vue Composition API是一定優於React Hooks的，比如：

Hooks不能在條件語句中宣告

Hooks必須顯式指明依賴

並且，這種易用性的差異會隨著框架迭代，愈發明顯。

useEffect會越來越複雜

本著保持API穩定的原則，當前useEffect主要與上述三個生命週期函數相關。

但是，未來會有更多觸發時機與useEffect掛鉤。

所以，React團隊在努力做一件事 —— 淡化useEffect與生命週期的關係，甚至淡化useEffect與元件的關係（因為當談到元件時，很自然的會想到元件生命週期）。

怎麼淡化呢？答案是 —— 在嚴格模式下，DEV環境會觸發多次useEffect回撥。

如果你將useEffect當作componentDidMount/WillUnmount來用，這個特性很可能讓你的程式碼出bug。

React團隊之所以這麼做，就是想教育開發者 —— useEffect和生命週期沒有關係。開發者應該將useEffect看作針對某個資料來源的同步過程。

比如，下述聊天室元件，其中的useEffect可以看作是針對聊天室連線的同步過程：

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

當聊天室元件mount、update、unmount時，對應的同步過程應該進行。

當roomId變化時，對應的同步過程應該進行。

同理，如果React原生支援了Vue中的KeepAlive，那麼當聊天室元件從可見變為不可見，以及從不可見變為可見狀態，同步過程都應該進行。

所以，當我們從同步過程應該何時進行的角度看待useEffect時，上述useEffect觸發時機都是合理的。

但是，如果從生命週期函數的角度看待useEffect，等未來（可能是v18的某個版本），Offscreen Component特性落地（對標Vue中的KeepAlive），元件從可見變為不可見狀態時，useEffect銷燬函數與useEffect回撥函數會依次執行，就會讓人很頭大。

這就是為什麼，我上文說，React團隊一直在淡化useEffect與生命週期的關係，甚至淡化useEffect與元件的關係。

一切都是為了未來其他特性與useEffect的掛鉤打下理論基礎。而這些特性從元件或生命週期函數的角度講不通。

這也是為什麼在新檔案裡有6節內容與useEffect相關的原因。

作為對比，Vue在遇到新的場景時會怎麼做呢？顯然是設計新的API。