一个新的个新概念React概念：Effect Event

作者：卡颂 2023-07-14 07:23:21开发 前端 在React中，有一个「非常容易」被误用的个新概念API —— UseEffect，今天要介绍的个新概念Effect Event就属于由useEffect衍生出的概念。首先来聊聊Event与Effect。个新概念useEffect容易被误用也是个新概念因为这两个概念很容易混淆。

大家好，个新概念我卡颂。个新概念

每个框架由于实现原理的个新概念区别，都会有些独特的个新概念概念。比如：

• 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方法会在什么情况下执行，因为：

1. useEffect的依赖项太多了
2. 很难完全掌握每个依赖项变化的时机

所以，在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个优点：

1. 不用显式声明依赖
2. 即使依赖变了，fn的引用也不会变，简直是性能优化的最佳选择

那么React为什么要为useEffectEvent加上限制呢？

实际上，useEffectEvent的前身useEvent就是遵循上述实现，但是由于：

1. useEvent的定位应该是Effect Event，但实际用途更广（可以替代useCallback），这不符合他的定位
2. 当前React Forget（能生成等效于useMemo、useCallback代码的官方编译器）并未考虑useEvent，如果增加这个hook，会提高React Forget实现的难度

所以，useEvent并没有正式进入标准。相反，拥有更多限制的useEffectEvent反而进入了React文档[1]。

总结

今天我们学到三个概念：

• Event：由某些行为触发，而不是状态变化触发的逻辑。
• Effect：由某些状态变化触发的，而不是某些行为触发的逻辑。
• Effect Event：在Effect内执行，但Effect并不依赖其中状态的逻辑。

其中Effect Event在React中的具体实现是useEffectEvent。相比于他的前身useEvent，他附加了2条限制：

1. 只能在Effect内执行。
2. 始终返回不同的引用。

在我看来，Effect Event的出现完全是由于Hooks实现机制上的复杂性（必须显式指明依赖）导致的心智负担。

毕竟，同样遵循Hooks理念的Vue Composition API就没有这方面问题。

参考资料

[1]React文档:https://react.dev/learn/separating-events-from-effects。

责任编辑：姜华 来源： 魔术师卡颂 ReactuseEffect

(责任编辑：休闲)