关于javascript:React新文档不要滥用effect哦

大家好，我卡颂。

你或你的共事在应用 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 中。

假如之前的代码逻辑是：

1. 点击按钮，触发 状态 a 变动
2. useEffect执行，发送申请

应该批改为：

1. 点击按钮，在事件回调中获取 状态 a 的值
2. 在事件回调中发送申请

通过这样批改，状态 a 变动 与发送申请 之间不再有因果关系，后续对 状态 a 的批改不会再有 无意间触发申请 的顾虑。

总结

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

对于组件中的副作用，首先应该明确：

是 用户行为触发的 还是 视图渲染后被动触发的？

对于前者，将逻辑放在 Event handlers 中解决。

对于后者，应用 useEffect 解决。

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