谈谈 React 的新提案：useEvent
2022 年 5 月 5 日，Dan Abramov 在 React RFC 上提交了一个新 hook 的提案：useEvent。其目标是返回一个永远援用不变(always-stable)的事件处理函数。
没有 useEvent 时咱们如何写事件函数
首先咱们来看一下这段代码
function Chat() {
const [text, setText] = useState("");
const onClick = () => {
sendMessage(text);
};
return <SendButton onClick={onClick} />;
}为了拜访最新的 state，onClick在每次Chat组件产生更新时，都会申明一个新的函数(援用变动)，这会导致SendButton组件每次都承受一个新的 prop，React 的比拟两个组件节点是否要 diff 前，会对 props 做浅比拟(Object.is)，所以每次 props 无意义的变动显然是对 diff 性能不利的。
同时它还会毁坏你的 memo 优化，比方你的SendButton做了如下设计：
const SendButton = React.memo(() => {});这时你可能会想到应用useMemo或者useCallback来优化父组件的onClick函数
function Chat() {
const [text, setText] = useState("");
const onClick = useCallback(() => {
sendMessage(text);
}, [text]);
return <SendButton onClick={onClick} />;
}然而这样当text变动时，援用还是会变动，仍然会带来子组件的不必要更新，设计不当甚至会触发子组件 useEffect 的 re-fired。SendButton基本不关怀text的变动。而且当函数非常复杂时，可能会漏写依赖（当然你能够通过 eslint 来保障），导致每次应用的都是初始 state，从而造成难以追踪的 bug。
而新的 hook 提案 useEvent，你能够做到这样：
function Chat() {
const [text, setText] = useState("");
const onClick = useEvent(() => {
sendMessage(text);
});
return <SendButton onClick={onClick} />;
}onClick曾经始终是援用不变的了，而且能够拜访到最新的 text。
useEvent 是如何实现的
它看上去如同很神奇，你也能够本人简略实现一个相似的 hook，最外围的中央就是应用 useRef 维持最新援用以及缓存住外层的 function：
const useEvent = (eventHandler) => {
const eventHandlerRef = useRef(eventHandler);
// 每次useEvent被调用都返回不变的值，但外部理论执行的是最新的函数
return useMemo((...args) => {
return eventHandlerRef.current(...args);
}, []);
};官网给的一个相似实现是这样的：
// (!) Approximate behavior
function useEvent(handler) {
const handlerRef = useRef(null);
// In a real implementation, this would run before layout effects
useLayoutEffect(() => {
handlerRef.current = handler;
});
return useCallback((...args) => {
// In a real implementation, this would throw if called during render
const fn = handlerRef.current;
return fn(...args);
}, []);
}其实，真正的实现比起上述两种形式要简单一些，作为一个应用度极广的框架，必须要须要思考一些边界条件和束缚。
- 在组件 render 时应用被 useEvent 包裹的函数须要抛出谬误。因为它的设计是为了包裹事件函数，事件函数不应该在 render 时调用。这也是为什么上述代码有
useLayoutEffect，它也保障了每次事件触发时都是最新的，因为视图/事件的更新肯定在useLayoutEffect之后。同时，useEvent 外部批改 state 也是平安的，因为它不会在 render 期间被调用，不会批改组件的 output。 - 其实
handlerRef.current的更新产生在比所有useLayoutEffect更提前的时刻，这个保障了当 layout 时，不会存在旧版本的 handler，不会呈现状态割裂的问题 - 第 1 处的设计还间接的优化了服务端渲染的平安和性能，因为它不能在 render 时运行，而服务端是不存在事件的，防止了报错。同时，既然 useEvent 对服务端渲染没有意义，那么服务端构建的包里能够跳过 useEvent 的打包，优化了包体积。
你什么时候不应该应用 useEvent
- 一般的函数（非事件回调）仍然用原来的 useCallback
function ThemedGrid() {
const theme = useContext(ThemeContext);
const renderItem = useCallback(
(item) => {
// Called during rendering, so it's not an event.
return <Row {...item} theme={theme} />;
},
[theme]
);
return <Grid renderItem={renderItem} />;
}因为有 render 期间的报错机制，开发者也不太可能在这种场景下用 useEvent
- 不是所有的 useEffect 依赖函数都应该是事件
function Chat({ selectedRoom }) {
const { createKeys } = useContext(EncryptionSettings);
// ...
useEffect(() => {
const socket = createSocket("/chat/" + selectedRoom, createKeys());
// ...
socket.connect();
return () => socket.disconnect();
}, [selectedRoom, createKeys]); // ✅ Re-runs when room or createKeys changes
}这里的createKeys不应该应用 useEvent，因为 effect 中的函数不是事件，也不须要放弃援用不变，因为它须要在createKeys变动时从新建设 socket
- 可能会导致 useEffect 不再响应式
上面是一个谬误的写法
function Chat({ selectedRoom, theme }) {
// ...
// 🔴 This should not be an event!
const createSocket = useEvent(() => {
const socket = createSocket("/chat/" + selectedRoom);
socket.on("connected", async () => {
await checkConnection(selectedRoom);
onConnected(selectedRoom);
});
socket.on("message", onMessage);
socket.connect();
return () => socket.disconnect();
});
useEffect(() => {
return createSocket();
}, []);
}要晓得一点的是，useEvent 是非响应式的。因为它是事件，最终会被动调用，并不需要随着状态变动而立刻响应。所以当selectedRoom变动时，effect 不再从新建设 socket 了，只管createSocket始终能够拿到最新的selectedRoom，但它须要的是被动触发。
正确的写法应该是应用useCallback且依赖selectedRoom，useEffect依赖useCallback
useEvent 的『毛病』是什么
- 毫无疑问它减少了 hooks 的概念，带来了更多的心智累赘，你须要判断这里该不该用 useEvent，还是用 useCallback
- 因为须要一个比 layoutEffect 更提前的期间，它不可避免的须要改变 fiber tree commit 阶段的逻辑。然而相比于让社区在第三方库中自行提供各自的不完满的解决方案，这种付出还是值得的。
- 它的体现仿佛超出了单纯的 event 边界，更应该叫
useStableCallback或者useCommittedCallback，官网给它取useEvent这一名字，是为了帮忙开发者们更容易建设『它应该被用于事件』这一心智模式。 - 它有一些非凡的边界条件下会呈现问题，不过这次要是因为代码编写有问题带来的，并不是它本身的问题。但正因为人是最难管制的，所以这种问题也是最难阻止的，开发者应该更留神本人的书写标准：
比方 useEvent 外面有异步逻辑
function App() {
const [count, setCount] = useState(0);
const sayCount = useEvent(async () => {
console.log(count);
await wait(1000);
console.log(count);
});
return <Child onClick={sayCount} />;
}await 前后输入值是一样的，因为 await 前面的回调保留了 count 闭包。count 仅仅是本次 render 的状态快照，所以函数内异步期待时，即使内部又把 count 改了，以后这次函数调用还是拿不到最新的 count，而 ref 办法是能够的。所以事件中尽量不要有异步。
另外还有『条件判断式的 event』，比方你写出了这样的代码onSomething={cond ? handler1 : handler2}，天然是没方法帮你放弃援用不变的。
此外在 react 更新中也会有『割裂』问题，unmounting layout effects 时应用的是上一次 render 时的 event，然而 非 layout effect 卸载时应用的是新版本的 event（下一次更新时的 event可能发生变化了）。这就相似于在 unmounting layout 和 non-layout effects 期间读 ref 后果不统一的状况。
集体对 useEvent 的认识
useEvent 次要作用是维持援用不变的事件，能够用非常简洁的代码缩小援用变动带来的问题。然而它自身也带来了更多的概念。正如下面的毛病里写的，你须要时刻留神那些问题。而且目前官网也仍然有一些待解决的问题https://github.com/reactjs/rfcs/blob/useevent/text/0000-useevent.md#unresolved-questions。总之对于这个 RFC 集体并没有太多欣慰，未来有则用，毕竟是官网给出的最佳实际，没有也能够有其余解决办法。
发表回复