React新文档:不要滥用Effect哦

摘要:随着需求不断迭代,其他地方也会修改 状态a 。但是在那个需求中,并不需要 状态a 改变后发起请求。你不想动之前的代码,又得修复这个 bug ,于是你增加了判断条件:

大家好,我卡颂。

你或你的同事在使用 useEffect 时有没有发生过以下场景:

当你希望 状态a 变化后「发起请求」,于是你使用了 useEffect :

useEffect(() => {
  fetch(xxx);
}, [a])

这段代码运行符合预期,上线后也没问题。

随着需求不断迭代,其他地方也会修改 状态a 。但是在那个需求中,并不需要 状态a 改变后发起请求。

你不想动之前的代码,又得修复这个 bug ,于是你增加了判断条件:

useEffect(() => {
  if (xxxx) {
    fetch(xxx);
  }
}, [a])

某一天,需求又变化了!现在请求还需要 b 字段。

这很简单,你顺手就将 b 作为 useEffect 的依赖加了进去:

useEffect(() => {
  if (xxxx) {
    fetch(xxx);
  }
}, [a, b])

随着时间推移,你逐渐发现:

  • 「是否发送请求」与「if条件」相关。
  • 「是否发送请求」还与「a、b等依赖项」相关。
  • 「a、b等依赖项」又与「很多需求」相关。

根本分不清到底什么时候会发送请求,真是头大...

如果以上场景似曾相识,那么 React 新文档里已经明确提供了解决办法。

一些理论知识

新文档中这一节名为Synchronizing with Effects,当前还处于草稿状态。

但是其中提到的一些概念,所有 React 开发者都应该清楚。

首先, effect 这一节隶属于Escape Hatches(逃生舱)这一章。


从命名就能看出,开发者并不一定需要使用 effect ,这仅仅是特殊情况下的逃生舱。

 React 中有两个重要的概念:

Rendering code
Event handlers

 Rendering code 指「开发者编写的组件渲染逻辑」,最终会返回一段 JSX 。

比如,如下组件内部就是 Rendering code :

function App() {
  const [name, update] = useState('KaSong');
  return <div>Hello {name}</div>;
}

 Rendering code 的特点是:他应该是「不带副作用的纯函数」。

如下 Rendering code 包含副作用( count 变化),就是不推荐的写法:

let count = 0;
function App() {
  count++;
  const [name, update] = useState('KaSong');
  return <div>Hello {name}</div>;
}

处理副作用

 Event handlers 是「组件内部包含的函数」,用于执行用户操作,可以包含 副作用 。

下面这些操作都属于 Event handlers :

input

如下例子中组件内部的 changeName 方法就属于 Event handlers :

function App() {
  const [name, update] = useState('KaSong');
  const changeName = () => {
    update('KaKaSong');
  } 
  return <div onClick={changeName}>Hello {name}</div>;
}

但是,并不是所有副作用都能在 Event handlers 中解决。

比如,在一个聊天室中,「发送消息」是用户触发的,应该交给 Event handlers 处理。

除此之外,聊天室需要随时保持和服务端的长连接,「保持长连接」的行为属于副作用,但并不是用户行为触发的。

对于这种:在视图渲染后触发的副作用,就属于 effect ,应该交给 useEffect 处理。

回到开篇的例子:

当你希望 状态a 变化后「发起请求」,首先应该明确,你的需求是:

「状态a变化,接下来需要发起请求」还是「某个用户行为需要发起请求,请求依赖状态a作为参数」?

如果是后者,这是用户行为触发的副作用,那么相关逻辑应该放在 Event handlers 中。

假设之前的代码逻辑是:

状态a
useEffect

应该修改为:

状态a

经过这样修改,「状态a变化」与「发送请求」之间不再有因果关系,后续对 状态a 的修改不会再有「无意间触发请求」的顾虑。

总结

当我们编写组件时,应该尽量将组件编写为纯函数。

对于组件中的副作用,首先应该明确:

是「用户行为触发的」还是「视图渲染后主动触发的」?

对于前者,将逻辑放在 Event handlers 中处理。

对于后者,使用 useEffect 处理。

这也是为什么 useEffect 所在章节在新文档中叫做 Escape Hatches  —— 大部分情况下,你不会用到 useEffect ,这只是其他情况都不适应时的逃生舱。

来源: 魔术师卡颂


本文内容仅供个人学习、研究或参考使用,不构成任何形式的决策建议、专业指导或法律依据。未经授权,禁止任何单位或个人以商业售卖、虚假宣传、侵权传播等非学习研究目的使用本文内容。如需分享或转载,请保留原文来源信息,不得篡改、删减内容或侵犯相关权益。感谢您的理解与支持!

链接: https://shenqiku.cn/article/FLY_11651