React新文档切记不要滥用effect_React
时间:2022-07-19 09:15 来源:网络 作者:澜薄 点击:次
引言
你或你的同事在使用
当你希望 useEffect(() => { fetch(xxx); }, [a]) 这段代码运行符合预期,上线后也没问题。
随着需求不断迭代,其他地方也会修改
你不想动之前的代码,又得修复这个 useEffect(() => { if (xxxx) { fetch(xxx); } }, [a])
某一天,需求又变化了!现在请求还需要
这很简单,你顺手就将 useEffect(() => { if (xxxx) { fetch(xxx); } }, [a, b]) 随着时间推移,你逐渐发现:
根本分不清到底什么时候会发送请求,真是头大...
如果以上场景似曾相识,那么
一些理论知识新文档中这一节名为Synchronizing with Effects,当前还处于草稿状态。
但是其中提到的一些概念,所有
首先,
从命名就能看出,开发者并不一定需要使用
比如,如下组件内部就是 function App() { const [name, update] = useState('KaSong'); return <div>Hello {name}</div>; }
如下 let count = 0; function App() { count++; const [name, update] = useState('KaSong'); return <div>Hello {name}</div>; }
处理副作用
下面这些操作都属于
如下例子中组件内部的 function App() { const [name, update] = useState('KaSong'); const changeName = () => { update('KaKaSong'); } return <div onClick={changeName}>Hello {name}</div>; }
但是,并不是所有副作用都能在
比如,在一个聊天室中,发送消息是用户触发的,应该交给 除此之外,聊天室需要随时保持和服务端的长连接,保持长连接的行为属于副作用,但并不是用户行为触发的。
对于这种:在视图渲染后触发的副作用,就属于 回到开篇的例子:
当你希望 状态a变化,接下来需要发起请求 还是 某个用户行为需要发起请求,请求依赖状态a作为参数?
如果是后者,这是用户行为触发的副作用,那么相关逻辑应该放在 假设之前的代码逻辑是:
应该修改为:
经过这样修改,状态a变化与发送请求之间不再有因果关系,后续对
总结当我们编写组件时,应该尽量将组件编写为纯函数。 对于组件中的副作用,首先应该明确: 是用户行为触发的还是视图渲染后主动触发的?
对于前者,将逻辑放在
对于后者,使用
这也是为什么 以上就是React新文档切记不要滥用effect的详细内容,更多关于React文档effect的资料请关注其它相关文章! |