新聞中心
大家好,我卡頌。

按需求定制網(wǎng)站可以根據(jù)自己的需求進(jìn)行定制,做網(wǎng)站、成都網(wǎng)站設(shè)計(jì)構(gòu)思過(guò)程中功能建設(shè)理應(yīng)排到主要部位公司做網(wǎng)站、成都網(wǎng)站設(shè)計(jì)的運(yùn)用實(shí)際效果公司網(wǎng)站制作網(wǎng)站建立與制做的實(shí)際意義
你或你的同事在使用??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??的依賴(lài)加了進(jìn)去:
useEffect(() => {
if (xxxx) {
fetch(xxx);
}
}, [a, b])隨著時(shí)間推移,你逐漸發(fā)現(xiàn):
- 「是否發(fā)送請(qǐng)求」與「if條件」相關(guān)。
- 「是否發(fā)送請(qǐng)求」還與「a、b等依賴(lài)項(xiàng)」相關(guān)。
- 「a、b等依賴(lài)項(xiàng)」又與「很多需求」相關(guān)。
根本分不清到底什么時(shí)候會(huì)發(fā)送請(qǐng)求,真是頭大...
如果以上場(chǎng)景似曾相識(shí),那么??React??新文檔里已經(jīng)明確提供了解決辦法。
一些理論知識(shí)
新文檔中這一節(jié)名為Synchronizing with Effects[1],當(dāng)前還處于草稿狀態(tài)。
但是其中提到的一些概念,所有??React??開(kāi)發(fā)者都應(yīng)該清楚。
首先,??effect??這一節(jié)隸屬于Escape Hatches[2](逃生艙)這一章。
從命名就能看出,開(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 Hello {name};
}??Rendering code??的特點(diǎn)是:他應(yīng)該是「不帶副作用的純函數(shù)」。
如下??Rendering code???包含副作用(??count??變化),就是不推薦的寫(xiě)法:
let count = 0;
function App() {
count++;
const [name, update] = useState('KaSong');
returnHello {name};
}
處理副作用
??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 Hello {name};
}但是,并不是所有副作用都能在??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)求依賴(lài)狀態(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í)的逃生艙。
參考資料
[1]Synchronizing with Effects:https://beta-reactjs-org-git-effects-fbopensource.vercel.app/learn/synchronizing-with-effects。
[2]Escape Hatches:https://beta-reactjs-org-git-effects-fbopensource.vercel.app/learn/escape-hatches?。
當(dāng)前題目:React新文檔:不要濫用Effect哦
分享網(wǎng)址:http://www.5511xx.com/article/djjocsg.html


咨詢
建站咨詢
