大家好，我卡颂。
每个框架由于实现原理的区别，都会有些独特的概念。比如：
-
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文档。
总结
今天我们学到三个概念：
-
Event：由某些行为触发，而不是状态变化触发的逻辑 -
Effect：由某些状态变化触发的，而不是某些行为触发的逻辑 -
Effect Event：在Effect内执行，但Effect并不依赖其中状态的逻辑
其中Effect Event在React中的具体实现是useEffectEvent。相比于他的前身useEvent，他附加了2条限制：
- 只能在
Effect内执行 - 始终返回不同的引用
在我看来，Effect Event的出现完全是由于Hooks实现机制上的复杂性（必须显式指明依赖）导致的心智负担。
毕竟，同样遵循Hooks理念的Vue Composition API就没有这方面问题。
