React 中最錯誤使用的 hook 肯定是 useEffect。我們這樣做有多種原因，而不僅僅是一個。讓我們從我的角度來探討其中的每一個。
所以我認為影響更大的原因之一是，在前鉤子時代，我們使用了類別。對於這個時期開始使用React的人來說，已經習慣了使用生命週期方法和this.state。我在這篇文章中寫了一些相關內容。有人懷念古老而黃金的階級時代，看重它的簡單直接。這個模型非常符合一般程式設計師的常識，學習物件導向和命令式編程，而心理結構恰好與該模型相關。
然後他們加了鉤子。
問題在於所發生的典範轉移。一般來說，程式設計師都非常熟悉命令式和物件導向範式，他們通常在大學和課程中教授，主要是命令式，遵循人類的共同思考流程。
當你切換到函數式程式設計等不同範式時，你會面臨一種相反的思考方式，這與常見的思考方式不太接近。這種「回歸」就更難理解了。
反應式程式也遇到同樣的問題。這是從主動程式設計方式到被動程式設計方式的轉變。我們看到它錯誤地使用了 useEffect。
大多數「錯誤」都是狀態同步。因此，開發人員使用 useEffect 來追蹤某些狀態或 prop，並基於某些邏輯來更改狀態。這個案例揭示了我們在這裡需要的相反的思維方式。
在 OOP 和命令式程式設計中，您是主動的，以主動的方式進行更改和邏輯。反應性是基於相反的情況，您對機會做出反應，並聲明您希望系統在狀態變更時執行的計算。
對於大多數用戶來說，在 useEffect 上主動設定新狀態是最直接的方式，狀態發生了變化，所以你需要手動追蹤變化並用它更新其他狀態。文件說不推薦，但沒有明確的原因。
在 React 中進行派生是推薦的方式，不僅是出於性能原因，而且是出於概念原因。 React 是一個推導機器，最終的結果就是 UI 的推導。您不需要主動處理這些狀態轉換和重新計算，它只是根據您編寫的聲明性程式碼發生。
React 文件沒有很好地解釋這一點，在 hooks 之後，React 核心團隊和內容創作者沒有進行演講或課程來解釋這些概念。
React 似乎存在“概念混亂”，向 hooks 的過渡是最有力的例子，但不是唯一的例子。 hooks 的使用有一個很大的區別，它是基於反應性的，儘管 React 核心團隊開玩笑說反應性，但他們決定切換到它。
功能組件非常適合它。每次重新渲染都會再次呼叫函數，並且內部的所有內容都會取得狀態和道具當前版本，因此，內部創建的所有內容都表現得像派生。回報，JSX，是UI的衍生。
但是 React 並不是函數式程式設計和反應性的完美和純粹的實作。它以概念和想法為靈感，並將它們融合起來創建自己的模型，但無論如何，核心就在那裡。
這一點需要明確。即使不是反應性的範例，它也使用了它們的概念，並且更深入地了解這些模式使開發人員可以輕鬆地使用這些原語思考和創建解決方案。順便說一句，這就是我寫這個「React 中的反應性」系列的原因。
不僅僅是對使用者說，“不要在 useEffect 上同步狀態，這很糟糕”，而是解釋為什麼它不好，以及如何以“同步狀態”甚至是第一個解決方案的方式思考。
這個原因正在改善，尤其是在 React 19 中。非同步派生是使用 useEffect 的原因之一，但現在我們必須使用原語，它在某些方面填補了這一空白。
當然，我們在原語中仍然存在一些弱點，例如動態派生的情況和其他情況，但是越來越多的 React 將更多的副作用移出了 hooks 字段，就像 ref 回調的情況一樣。
我們總是可以期待未來的消息。我邀請大家閱讀 React 中的所有其他 Reactivity 帖子，並帶來具體的案例和問題，我們可以探索並找到這些常見反應性問題的更多解決方案。
以上是關於useEffect錯誤用法的推理的詳細內容。更多資訊請關注PHP中文網其他相關文章！
