React新文档：不要滥用Effect哦

大家好，我卡颂。,你或你的同事在使用​​useEffect​​时有没有发生过以下场景：,当你希望​​状态a​​​变化后「发起请求」，于是你使用了​​useEffect​​：,这段代码运行符合预期，上线后也没问题。,随着需求不断迭代，其他地方也会修改​​状态a​​​。但是在那个需求中，并不需要​​状态a​​改变后发起请求。,你不想动之前的代码，又得修复这个​​bug​​，于是你增加了判断条件：,某一天，需求又变化了！现在请求还需要​​b​​字段。,这很简单，你顺手就将​​b​​​作为​​useEffect​​的依赖加了进去：,随着时间推移，你逐渐发现：,根本分不清到底什么时候会发送请求，真是头大...,如果以上场景似曾相识，那么​​React​​新文档里已经明确提供了解决办法。,新文档中这一节名为Synchronizing with Effects[1]，当前还处于草稿状态。,但是其中提到的一些概念，所有​​React​​开发者都应该清楚。,首先，​​effect​​这一节隶属于Escape Hatches[2]（逃生舱）这一章。,从命名就能看出，开发者并不一定需要使用​​effect​​，这仅仅是特殊情况下的逃生舱。,​​React​​中有两个重要的概念：,​​Rendering code​​​指「开发者编写的组件渲染逻辑」，最终会返回一段​​JSX​​。,比如，如下组件内部就是​​Rendering code​​：,​​Rendering code​​的特点是：他应该是「不带副作用的纯函数」。,如下​​Rendering code​​​包含副作用（​​count​​变化），就是不推荐的写法：,​​Event handlers​​​是「组件内部包含的函数」，用于执行用户操作，可以包含​​副作用​​。,下面这些操作都属于​​Event handlers​​：,如下例子中组件内部的​​changeName​​​方法就属于​​Event handlers​​：,但是，并不是所有副作用都能在​​Event handlers​​中解决。,比如，在一个聊天室中，「发送消息」是用户触发的，应该交给​​Event handlers​​处理。,除此之外，聊天室需要随时保持和服务端的长连接，「保持长连接」的行为属于副作用，但并不是用户行为触发的。,对于这种：在视图渲染后触发的副作用，就属于​​effect​​​，应该交给​​useEffect​​处理。,回到开篇的例子：,当你希望​​状态a​​变化后「发起请求」，首先应该明确，你的需求是：,「状态a变化，接下来需要发起请求」还是「某个用户行为需要发起请求，请求依赖状态a作为参数」？,如果是后者，这是用户行为触发的副作用，那么相关逻辑应该放在​​Event handlers​​中。,假设之前的代码逻辑是：,应该修改为：,经过这样修改，「状态a变化」与「发送请求」之间不再有因果关系，后续对​​状态a​​的修改不会再有「无意间触发请求」的顾虑。,当我们编写组件时，应该尽量将组件编写为纯函数。,对于组件中的副作用，首先应该明确：,是「用户行为触发的」还是「视图渲染后主动触发的」？,对于前者，将逻辑放在​​Event handlers​​中处理。,对于后者，使用​​useEffect​​处理。,这也是为什么​​useEffect​​​所在章节在新文档中叫做​​Escape Hatches​​​ —— 大部分情况下，你不会用到​​useEffect​​，这只是其他情况都不适应时的逃生舱。,[1]Synchronizing with Effects:https://beta-reactjs-org-git-effects-fbopensource.vercel.app/learn/synchronizing-with-effects。,[2]Escape Hatches:https://beta-reactjs-org-git-effects-fbopensource.vercel.app/learn/escape-hatches​。