網站首頁 編程語言 正文
引言
你或你的同事在使用useEffect
時有沒有發生過以下場景:
當你希望狀態a
變化后發起請求,于是你使用了useEffect
:
useEffect(() => { fetch(xxx); }, [a])
這段代碼運行符合預期,上線后也沒問題。
隨著需求不斷迭代,其他地方也會修改狀態a
。但是在那個需求中,并不需要狀態a
改變后發起請求。
你不想動之前的代碼,又得修復這個bug
,于是你增加了判斷條件:
useEffect(() => { if (xxxx) { fetch(xxx); } }, [a])
某一天,需求又變化了!現在請求還需要b
字段。
這很簡單,你順手就將b
作為useEffect
的依賴加了進去:
useEffect(() => { if (xxxx) { fetch(xxx); } }, [a, b])
隨著時間推移,你逐漸發現:
- 是否發送請求與if條件相關
- 是否發送請求還與a、b等依賴項相關
- a、b等依賴項又與很多需求相關
根本分不清到底什么時候會發送請求,真是頭大...
如果以上場景似曾相識,那么React
新文檔里已經明確提供了解決辦法。
一些理論知識
新文檔中這一節名為Synchronizing with Effects,當前還處于草稿狀態。
但是其中提到的一些概念,所有React
開發者都應該清楚。
首先,effect
這一節隸屬于Escape Hatches(逃生艙)這一章。
從命名就能看出,開發者并不一定需要使用effect
,這僅僅是特殊情況下的逃生艙。
React
中有兩個重要的概念:
Rendering code
(渲染代碼)
Event handlers
(事件處理器)
Rendering code
指開發者編寫的組件渲染邏輯,最終會返回一段JSX
。
比如,如下組件內部就是Rendering code
:
function App() { const [name, update] = useState('KaSong'); return <div>Hello {name}</div>; }
Rendering code
的特點是:他應該是不帶副作用的純函數。
如下Rendering code
包含副作用(count
變化),就是不推薦的寫法:
let count = 0; function App() { count++; const [name, update] = useState('KaSong'); return <div>Hello {name}</div>; }
處理副作用
Event handlers
是組件內部包含的函數,用于執行用戶操作,可以包含副作用
。
下面這些操作都屬于Event handlers
:
- 更新
input
輸入框 - 提交表單
- 導航到其他頁面
如下例子中組件內部的changeName
方法就屬于Event handlers
:
function App() { const [name, update] = useState('KaSong'); const changeName = () => { update('KaKaSong'); } return <div onClick={changeName}>Hello {name}</div>; }
但是,并不是所有副作用都能在Event handlers
中解決。
比如,在一個聊天室中,發送消息是用戶觸發的,應該交給Event handlers
處理。
除此之外,聊天室需要隨時保持和服務端的長連接,保持長連接的行為屬于副作用,但并不是用戶行為觸發的。
對于這種:在視圖渲染后觸發的副作用,就屬于effect
,應該交給useEffect
處理。
回到開篇的例子:
當你希望狀態a
變化后發起請求,首先應該明確,你的需求是:
狀態a變化,接下來需要發起請求
還是
某個用戶行為需要發起請求,請求依賴狀態a作為參數?
如果是后者,這是用戶行為觸發的副作用,那么相關邏輯應該放在Event handlers
中。
假設之前的代碼邏輯是:
- 點擊按鈕,觸發
狀態a
變化 -
useEffect
執行,發送請求
應該修改為:
- 點擊按鈕,在事件回調中獲取
狀態a
的值 - 在事件回調中發送請求
經過這樣修改,狀態a變化與發送請求之間不再有因果關系,后續對狀態a
的修改不會再有無意間觸發請求的顧慮。
總結
當我們編寫組件時,應該盡量將組件編寫為純函數。
對于組件中的副作用,首先應該明確:
是用戶行為觸發的還是視圖渲染后主動觸發的?
對于前者,將邏輯放在Event handlers
中處理。
對于后者,使用useEffect
處理。
這也是為什么useEffect
所在章節在新文檔中叫做Escape Hatches
—— 大部分情況下,你不會用到useEffect
,這只是其他情況都不適應時的逃生艙。
原文鏈接:https://juejin.cn/post/7105940800848003086
相關推薦
- 2022-09-12 python中的集合及集合常用的使用方法_python
- 2022-10-31 Python3中的算術運算符詳解_python
- 2022-06-30 Go實現分布式唯一ID的生成之雪花算法_Golang
- 2022-09-08 Go語言中的包Package詳解_Golang
- 2022-04-27 簡單聊聊PyTorch里面的torch.nn.Parameter()_python
- 2022-03-15 Response to preflight request doesn‘t pass access
- 2022-04-06 關于Redis數據庫三種持久化方案介紹_Redis
- 2023-07-25 使用POI導出Excel
- 最近更新
-
- window11 系統安裝 yarn
- 超詳細win安裝深度學習環境2025年最新版(
- Linux 中運行的top命令 怎么退出?
- MySQL 中decimal 的用法? 存儲小
- get 、set 、toString 方法的使
- @Resource和 @Autowired注解
- Java基礎操作-- 運算符,流程控制 Flo
- 1. Int 和Integer 的區別,Jav
- spring @retryable不生效的一種
- Spring Security之認證信息的處理
- Spring Security之認證過濾器
- Spring Security概述快速入門
- Spring Security之配置體系
- 【SpringBoot】SpringCache
- Spring Security之基于方法配置權
- redisson分布式鎖中waittime的設
- maven:解決release錯誤:Artif
- restTemplate使用總結
- Spring Security之安全異常處理
- MybatisPlus優雅實現加密?
- Spring ioc容器與Bean的生命周期。
- 【探索SpringCloud】服務發現-Nac
- Spring Security之基于HttpR
- Redis 底層數據結構-簡單動態字符串(SD
- arthas操作spring被代理目標對象命令
- Spring中的單例模式應用詳解
- 聊聊消息隊列,發送消息的4種方式
- bootspring第三方資源配置管理
- GIT同步修改后的遠程分支