一個新的React概念：Effect Event
大家好，我卡頌。
每個框架由于實現原理的區別，都會有些獨特的概念。比如：
- Vue3由于其響應式的實現原理，衍生出ref、reactive等概念。
- Svelte重度依賴自身的編譯器，所以衍生出與編譯相關的概念（比如其對label標簽的創新性使用）。
在React中，有一個「非常容易」被誤用的API —— useEffect，今天要介紹的Effect Event就屬于由useEffect衍生出的概念。
被誤用的useEffect
本文一共會涉及三個概念：
- Event（事件）
- Effect（副作用）
- Effect Event（副作用事件）
首先來聊聊Event與Effect。useEffect容易被誤用也是因為這兩個概念很容易混淆。
Event的概念
在下面的代碼中，點擊div會觸發點擊事件，onClick是點擊回調。其中onClick就屬于Event：
function App() {
const [num , update] = useState(0);
function onClick() {
update(num + 1);
}
return (
<div onClick={onClick}>{num}</div>
)
}Event的特點是：「是由某些行為觸發，而不是狀態變化觸發的邏輯」。
比如，在上述代碼中，onClick是由「點擊事件」這一行為觸發的邏輯，num狀態變化不會觸發onClick。
Effect的概念
Effect則與Event相反，他是「由某些狀態變化觸發的，而不是某些行為觸發的邏輯」。
比如，在下述代碼中，當title變化后document.title會更新為title的值：
function Title({title}) {
useEffect(() => {
document.title = title;
}, [title])
// ...
}上述代碼中useEffect的邏輯就屬于Effect，他是由title變化觸發的。除了useEffect外，下面兩個Hook也屬于Effect：
- useLayoutEffect（不常用）
- useInsertionEffect（很不常用）
為什么容易誤用？
現在問題來了：Event與Effect的概念完全不同，為什么會被誤用？
舉個例子，在項目的第一個版本中，我們在useEffect中有個初始化數據的邏輯：
function App() {
const [data, updateData] = useState(null);
useEffect(() => {
fetchData().then(data => {
// ...一些業務邏輯
// 更新data
updateData(data);
})
}, []);
// ...
}隨著項目發展，你又接到一個需求：提交表單后更新數據。
為了復用之前的邏輯，你新增了options狀態（保存表單數據），并將他作為useEffect的依賴：
function App() {
const [data, updateData] = useState(null);
const [options, updateOptions] = useState(null);
useEffect(() => {
fetchData(options).then(data => {
// ...一些業務邏輯
// 更新data
updateData(data);
})
}, [options]);
function onSubmit(opt) {
updateOptions(opt);
}
// ...
}現在，提交表單后（觸發onSubmit回調）就能復用之前的數據初始化邏輯。
這么做實在是方便，以至于很多同學認為這就是useEffect的用法。但其實這是典型的「useEffect誤用」。
仔細分析我們會發現：「提交表單」顯然是個Event（由提交的行為觸發），Event的邏輯應該寫在事件回調中，而不是useEffect中。正確的寫法應該是這樣：
function App() {
const [data, updateData] = useState(null);
useEffect(() => {
fetchData().then(data => {
// ...一些業務邏輯
// 更新data
updateData(data);
})
}, []);
function onSubmit(opt) {
fetchData(opt).then(data => {
// ...一些業務邏輯
// 更新data
updateData(data);
})
}
// ...
}上述例子邏輯比較簡單，兩種寫法的區別不大。但在實際項目中，隨著項目不斷迭代，可能出現如下代碼：
useEffect(() => {
fetchData(options).then(data => {
// ...一些業務邏輯
// 更新data
updateData(data);
})
}, [options, xxx, yyy, zzz]);屆時，很難清楚fetchData方法會在什么情況下執行，因為：
- useEffect的依賴項太多了
- 很難完全掌握每個依賴項變化的時機
所以，在React中，我們需要清楚的區分Event與Effect，也就是清楚的區分「一段邏輯是由行為觸發的，還是狀態變化觸發的？」
useEffect的依賴問題
現在，我們已經能清楚的區分Event與Effect，按理說寫項目不會有問題了。但是，由于「Effect的機制問題」，我們還面臨一個新問題。
假設我們有段聊天室代碼，當roomId變化后，要重新連接到新聊天室。在這個場景下，聊天室的斷開/重新連接依賴于roomId狀態的變化，顯然屬于Effect，代碼如下：
function ChatRoom({roomId}) {
useEffect(() => {
const connection = createConnection(roomId);
connection.connect();
return () => {
connection.disconnect()
};
}, [roomId]);
// ...
}接下來你接到了新需求 —— 當連接成功后，彈出「全局提醒」：
「全局提醒」是否是黑暗模式，受到theme props影響。useEffect修改后的代碼如下：
useEffect(() => {
const connection = createConnection(roomId);
connection.connect();
connection.on('connected', () => {
showNotification('連接成功!', theme);
});
return () => connection.disconnect();
}, [roomId, theme]);但這段代碼有個嚴重問題 —— 任何導致theme變化的情況都會導致聊天室斷開/重新連接。畢竟，theme也是useEffect的依賴項。
在這個例子中，雖然Effect依賴theme，但Effect并不是由theme變化而觸發的（他是由roomId變化觸發的）。
為了應對這種場景，React提出了一個新概念 —— Effect Event。他指那些「在Effect內執行，但Effect并不依賴其中狀態的邏輯」，比如上例中的：
() => {
showNotification('連接成功!', theme);
}我們可以使用useEffectEvent（這是個試驗性Hook）定義Effect Event：
function ChatRoom({roomId, theme}) {
const onConnected = useEffectEvent(() => {
showNotification('連接成功!', theme);
});
useEffect(() => {
const connection = createConnection(roomId);
connection.connect();
connection.on('connected', () => {
onConnected();
});
return () => {
connection.disconnect()
};
}, [roomId]);
// ...
}在上面代碼中，theme被移到onConnected（他是個Effect Event）中，useEffect雖然使用了theme的最新值，但并不需要將他作為依賴。
useEffectEvent源碼解析
useEffectEvent的實現并不復雜，核心代碼如下：
function updateEvent(callback) {
const hook = updateWorkInProgressHook();
// 保存callback的引用
const ref = hook.memoizedState;
// 在useEffect執行前更新callback的引用
useEffectEventImpl({ref, nextImpl: callback});
return function eventFn() {
if (isInvalidExecutionContextForEventFunction()) {
throw new Error(
"A function wrapped in useEffectEvent can't be called during rendering.",
);
}
return ref.impl.apply(undefined, arguments);
};
}其中ref變量保存「callback的引用」。對于上述例子中：
const onConnected = useEffectEvent(() => {
showNotification('連接成功!', theme);
});ref保存對如下函數的引用：
() => {
showNotification('連接成功!', theme);
}useEffectEventImpl方法接受ref和callback的最新值為參數，在useEffect執行前會將ref中保存的callback引用更新為callback的最新值。
所以，當在useEffect中執行onConnected，獲取的就是ref中保存的下述閉包的最新值：
() => {
showNotification('連接成功!', theme);
}閉包中的theme自然也是最新值。
useEffectEvent與useEvent
仔細觀察下useEffectEvent的返回值，他包含了兩個限制：
return function eventFn() {
if (isInvalidExecutionContextForEventFunction()) {
throw new Error(
"A function wrapped in useEffectEvent can't be called during rendering.",
);
}
return ref.impl.apply(undefined, arguments);
};第一個限制比較明顯 —— 下面這行代碼限制useEffectEvent的返回值只能在useEffect回調中執行（否則會報錯）：
if (isInvalidExecutionContextForEventFunction()) {
// ...
}另一個限制則比較隱晦 —— 返回值是個全新的引用：
return function eventFn() {
// ...
};如果你不太明白「全新的引用」為什么是個限制，考慮下返回一個useCallback返回值：
return useCallback((...args) => {
const fn = ref.impl;
return fn(...args);
}, []);這將會讓useEffectEvent的返回值成為不變的引用，如果再去掉「只能在useEffect回調中執行」的限制，那么useEffectEvent將是加強版的useCallback。
舉個例子，如果破除上述限制，那么對于下面的代碼：
function App({a, b}) {
const [c, updateC] = useState(0);
const fn = useCallback(() => a + b + c, [a, b, c])
// ...
}用useEffectEvent替代useCallback，代碼如下：
const fn = useEffectEvent(() => a + b + c)相比于useCallback，他有2個優點：
- 不用顯式聲明依賴
- 即使依賴變了，fn的引用也不會變，簡直是性能優化的最佳選擇
那么React為什么要為useEffectEvent加上限制呢？
實際上，useEffectEvent的前身useEvent就是遵循上述實現，但是由于：
- useEvent的定位應該是Effect Event，但實際用途更廣（可以替代useCallback），這不符合他的定位
- 當前React Forget（能生成等效于useMemo、useCallback代碼的官方編譯器）并未考慮useEvent，如果增加這個hook，會提高React Forget實現的難度
所以，useEvent并沒有正式進入標準。相反，擁有更多限制的useEffectEvent反而進入了React文檔[1]。
總結
今天我們學到三個概念：
- Event：由某些行為觸發，而不是狀態變化觸發的邏輯。
- Effect：由某些狀態變化觸發的，而不是某些行為觸發的邏輯。
- Effect Event：在Effect內執行，但Effect并不依賴其中狀態的邏輯。
其中Effect Event在React中的具體實現是useEffectEvent。相比于他的前身useEvent，他附加了2條限制：
- 只能在Effect內執行。
- 始終返回不同的引用。
在我看來，Effect Event的出現完全是由于Hooks實現機制上的復雜性（必須顯式指明依賴）導致的心智負擔。
畢竟，同樣遵循Hooks理念的Vue Composition API就沒有這方面問題。
參考資料
[1]React文檔:https://react.dev/learn/separating-events-from-effects。
