大家好，我卡颂。
你或你的共事在应用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，这只是其余状况都不适应时的逃生舱。
发表回复