引言

你或你的同事在使用useEffect時(shí)有沒(méi)有發(fā)生過(guò)以下場(chǎng)景：

當(dāng)你希望狀態(tài)a變化后發(fā)起請(qǐng)求，于是你使用了useEffect：

useEffect(() => {
  fetch(xxx);
}, [a])

這段代碼運(yùn)行符合預(yù)期，上線后也沒(méi)問(wèn)題。

隨著需求不斷迭代，其他地方也會(huì)修改狀態(tài)a。但是在那個(gè)需求中，并不需要狀態(tài)a改變后發(fā)起請(qǐng)求。

你不想動(dòng)之前的代碼，又得修復(fù)這個(gè)bug，于是你增加了判斷條件：

useEffect(() => {
  if (xxxx) {
    fetch(xxx);
  }
}, [a])

某一天，需求又變化了！現(xiàn)在請(qǐng)求還需要b字段。

這很簡(jiǎn)單，你順手就將b作為useEffect的依賴加了進(jìn)去：

useEffect(() => {
  if (xxxx) {
    fetch(xxx);
  }
}, [a, b])

隨著時(shí)間推移，你逐漸發(fā)現(xiàn)：

• 是否發(fā)送請(qǐng)求與if條件相關(guān)
• 是否發(fā)送請(qǐng)求還與a、b等依賴項(xiàng)相關(guān)
• a、b等依賴項(xiàng)又與很多需求相關(guān)

根本分不清到底什么時(shí)候會(huì)發(fā)送請(qǐng)求，真是頭大...

如果以上場(chǎng)景似曾相識(shí)，那么React新文檔里已經(jīng)明確提供了解決辦法。

一些理論知識(shí)

新文檔中這一節(jié)名為Synchronizing with Effects，當(dāng)前還處于草稿狀態(tài)。

但是其中提到的一些概念，所有React開(kāi)發(fā)者都應(yīng)該清楚。

首先，effect這一節(jié)隸屬于Escape Hatches（逃生艙）這一章。

從命名就能看出，開(kāi)發(fā)者并不一定需要使用effect，這僅僅是特殊情況下的逃生艙。

React中有兩個(gè)重要的概念：

Rendering code（渲染代碼）

Event handlers（事件處理器）

Rendering code指開(kāi)發(fā)者編寫(xiě)的組件渲染邏輯，最終會(huì)返回一段JSX。

比如，如下組件內(nèi)部就是Rendering code：

function App() {
  const [name, update] = useState('KaSong');
  return <div>Hello {name}</div>;
}

Rendering code的特點(diǎn)是：他應(yīng)該是不帶副作用的純函數(shù)。

如下Rendering code包含副作用（count變化），就是不推薦的寫(xiě)法：

let count = 0;
function App() {
  count++;
  const [name, update] = useState('KaSong');
  return <div>Hello {name}</div>;
}

處理副作用

Event handlers是組件內(nèi)部包含的函數(shù)，用于執(zhí)行用戶操作，可以包含副作用。

下面這些操作都屬于Event handlers：

• 更新input輸入框
• 提交表單
• 導(dǎo)航到其他頁(yè)面

如下例子中組件內(nèi)部的changeName方法就屬于Event handlers：

function App() {
  const [name, update] = useState('KaSong');
  const changeName = () => {
    update('KaKaSong');
  }
  return <div onClick={changeName}>Hello {name}</div>;
}

但是，并不是所有副作用都能在Event handlers中解決。

比如，在一個(gè)聊天室中，發(fā)送消息是用戶觸發(fā)的，應(yīng)該交給Event handlers處理。

除此之外，聊天室需要隨時(shí)保持和服務(wù)端的長(zhǎng)連接，保持長(zhǎng)連接的行為屬于副作用，但并不是用戶行為觸發(fā)的。

對(duì)于這種：在視圖渲染后觸發(fā)的副作用，就屬于effect，應(yīng)該交給useEffect處理。

回到開(kāi)篇的例子：

當(dāng)你希望狀態(tài)a變化后發(fā)起請(qǐng)求，首先應(yīng)該明確，你的需求是：

狀態(tài)a變化，接下來(lái)需要發(fā)起請(qǐng)求

還是

某個(gè)用戶行為需要發(fā)起請(qǐng)求，請(qǐng)求依賴狀態(tài)a作為參數(shù)？

如果是后者，這是用戶行為觸發(fā)的副作用，那么相關(guān)邏輯應(yīng)該放在Event handlers中。

假設(shè)之前的代碼邏輯是：

• 點(diǎn)擊按鈕，觸發(fā)狀態(tài)a變化
• useEffect執(zhí)行，發(fā)送請(qǐng)求

應(yīng)該修改為：

• 點(diǎn)擊按鈕，在事件回調(diào)中獲取狀態(tài)a的值
• 在事件回調(diào)中發(fā)送請(qǐng)求

經(jīng)過(guò)這樣修改，狀態(tài)a變化與發(fā)送請(qǐng)求之間不再有因果關(guān)系，后續(xù)對(duì)狀態(tài)a的修改不會(huì)再有無(wú)意間觸發(fā)請(qǐng)求的顧慮。

總結(jié)

當(dāng)我們編寫(xiě)組件時(shí)，應(yīng)該盡量將組件編寫(xiě)為純函數(shù)。

對(duì)于組件中的副作用，首先應(yīng)該明確：

是用戶行為觸發(fā)的還是視圖渲染后主動(dòng)觸發(fā)的？

對(duì)于前者，將邏輯放在Event handlers中處理。

對(duì)于后者，使用useEffect處理。

這也是為什么useEffect所在章節(jié)在新文檔中叫做Escape Hatches —— 大部分情況下，你不會(huì)用到useEffect，這只是其他情況都不適應(yīng)時(shí)的逃生艙。

以上就是React新文檔切記不要濫用effect的詳細(xì)內(nèi)容，更多關(guān)于React文檔effect的資料請(qǐng)關(guān)注腳本之家其它相關(guān)文章！

最新評(píng)論