React新文档：不要滥用effect哦

作者：卡颂

简介：《React技术揭秘》作者

来源：SegmentFault  思否社区 

大家好，我卡颂。

你或你的同事在使用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 变化

useEffec t执行，发送请求

应该修改为：

点击按钮，在事件回调中获取 状态a 的值

在事件回调中发送请求

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

总结

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

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

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

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

对于后者，使用 useEffect 处理。

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