大家好,我卡颂。
你或你的同事在使用 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])
随着时间推移,你逐渐发现:
根本分不清到底什么时候会发送请求,真是头大...
如果以上场景似曾相识,那么 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 ,这只是其他情况都不适应时的逃生舱。
来源: 魔术师卡颂
如今的 Web 前端已被 React、Vue 和 Angular 三分天下,尽管现在的 jQuery 已不再那么流行,但 jQuery 的设计思想还是非常值得致敬和学习的,特别是 jQuery 的插件化。
受控组件与非受控组件在官网与国内网上的资料都不多,有些人觉得它可有可不有,也不在意。这恰恰显示React的威力,满足不同规模大小的工程需求。
一般在传统模式下,我们构建前端项目很简单。就是下载各种js文件,如JQuery、Echart等,直接放置在html静态文件。Webpack则是JavaScript中比较知名的打包工具。这两个构建工具构成了React应用快速搭建的基础。
Gatsby能快速的使用 React 生态系统来生成静态网站,可以结合React Component、Markdown 和服务端渲染来完成静态网站生成让他更强大。
React推出后,出于不同的原因先后出现三种定义react组件的方式,殊途同归;具体的三种方式:函数式定义的无状态组件、es5原生方式React.createClass定义的组件、es6形式的extends React.Component定义的组件
React主要思想是通过构建可复用组件来构建用户界面,每个组件都有自己的生命周期,它规定了组件的状态和方法需要在哪个阶段改变和执行。所谓组件就是有限状态机,,表示有限个状态以及在这些状态之间的转移和动作行为的模型。
React 相关的优化:使用 babel-react-optimize 对 React 代码进行优化,检查没有使用的库,去除 import 引用,按需打包所用的类库,比如 lodash 、echarts 等.Webpack 构建打包存在的问题两个方面:构建速度慢,打包后的文件体积过大
这篇文章主要介绍React Router定义路由之后如何传值,有关React和React Router 。react router中页面传值的三种方法:props.params、query、state
react 高阶组件简单的理解是:一个包装了另一个基础组件的组件。高阶组件的两种形式:属性代理(Props Proxy)、反向继承 (Inheritance Inversion)
React 支持一种非常特殊的属性 Ref ,你可以用来绑定到 render() 输出的任何组件上。这个特殊的属性允许你引用 render() 返回的相应的支撑实例( backing instance )。这样就可以确保在任何时间总是拿到正确的实例
内容以共享、参考、研究为目的,不存在任何商业目的。其版权属原作者所有,如有侵权或违规,请与小编联系!情况属实本人将予以删除!