likes
comments
collection
share

解读 React useEvent RFC

作者站长头像
站长
· 阅读数 85

谈谈 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);
  }, []);
}

其实，真正的实现比起上述两种方式要复杂一些，作为一个使用度极广的框架，必须要需要考虑一些边界条件和约束。

  1. 在组件 render 时使用被 useEvent 包裹的函数需要抛出错误。因为它的设计是为了包裹事件函数，事件函数不应该在 render 时调用。这也是为什么上述代码有useLayoutEffect，它也保证了每次事件触发时都是最新的，因为视图/事件的更新一定在useLayoutEffect之后。同时，useEvent 内部修改 state 也是安全的，因为它不会在 render 期间被调用，不会修改组件的 output。
  2. 其实handlerRef.current的更新发生在比所有useLayoutEffect更提前的时刻，这个保证了当 layout 时，不会存在旧版本的 handler，不会出现状态割裂的问题
  3. 第 1 处的设计还间接的优化了服务端渲染的安全和性能，因为它不能在 render 时运行，而服务端是不存在事件的，避免了报错。同时，既然 useEvent 对服务端渲染没有意义，那么服务端构建的包里可以跳过 useEvent 的打包，优化了包体积。

你什么时候不应该使用 useEvent

  1. 普通的函数（非事件回调）依然用原来的 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

  1. 不是所有的 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

  1. 可能会导致 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 的『缺点』是什么

  1. 毫无疑问它增加了 hooks 的概念，带来了更多的心智负担，你需要判断这里该不该用 useEvent，还是用 useCallback
  2. 由于需要一个比 layoutEffect 更提前的时期，它不可避免的需要改动 fiber tree commit 阶段的逻辑。但是相比于让社区在第三方库中自行提供各自的不完美的解决方案，这种付出还是值得的。
  3. 它的表现似乎超出了单纯的 event 边界，更应该叫useStableCallback或者useCommittedCallback，官方给它取useEvent这一名字，是为了帮助开发者们更容易建立『它应该被用于事件』这一心智模式。
  4. 它有一些特殊的边界条件下会出现问题，不过这主要是因为代码编写有问题带来的，并不是它自身的问题。但正因为人是最难控制的，所以这种问题也是最难阻止的，开发者应该更注意自己的书写规范：

比如 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 个人并没有太多欣喜，将来有则用，毕竟是官方给出的最佳实践，没有也可以有其他解决办法。

转载自:https://segmentfault.com/a/1190000041989868
评论
请登录