如何理解Js事件的防抖与节流?

JavaScript012

如何理解Js事件的防抖与节流?,第1张

在平时的编码过程中,当绐浏览器注册一个时间,经常会遇到一些执行次数非常频繁的事件,如scroll,resize等,事件频繁的执行会导致浏览器进行大量的计算而引发页面卡顿假死的情况,为些我们需要通过一些手段来解决这个问题,所以就有了防抖和节流这两个技术。

是指在某段时间内,不管你触发了多少次回调事件,我都只认第一次,并在计时结束时给予响应,至于后面你再触发多少次回调我都不会予以回应。代码实现如下:

与事件节流怡好相反,事件防抖只认最后一次,不管你前面触发了多少次我都不管,我只执行你最后一次触发事件的回调,代码实现如下:

连续的事件,只需触发一次回调的场景有:

间隔一段时间执行一次回调的场景有:

涉及ts的变量声明、接口、类、函数、泛型等

ts语法知识

前提:定义了一个 Fecth 类,用于处理请求数据。

1)用法

2)源码分析

第一次调用时,缓存中不存在数据,则会自动执行获取数据

1)用法

2)源码分析

当开启 manual 禁止自动请求时,将 run 函数暴露给用户调用。

如果 fetchKey 不存在,则新建 Fetch 实例,保存到 feches 对象中,并调用实例的 run ,最后返回调用结果数据。

如果 fetchKey 存在,则直接调用 Fetch 实例的 run 。

作用:在取数结束后设定 setTimeout 重新触发下一轮取数。

1)用法

2)源码分析

在 Fetch 类中 _run(...args: P) 的实际取值函数中,最后会判断,是否设置了轮询 pollingInterval ,设置了则开启定时器。 注意,前提是当前页面没有被隐藏。

定时器及时销毁:在 _run 函数最开始,会对现有的定时器先进行销毁。

作用:设置 options.cacheKey 后开启对请求结果缓存机制,下次请求前会优先返回缓存并在后台重新取数。

1)用法

2)源码分析

每次请求都是创建一个 Fetch 实例,并用 fetchKey 进行唯一标识,并且调用 run 函数时,优先调用缓存实例。

1)用法

2)源码分析

根据传入的 config 配置来判断是否进行防抖和节流分发处理。

1)用法

2)源码分析

预加载本质是缓存机制,通过利用 useEffect 同步缓存实例, 保证缓存数据的最新,然后当需要用到数据时,优先调用缓存实例。

1)用法

2)源码分析

1)用法

2)源码分析

调用 mutate 传入的方法

分页:设置 options.paginated 支持分页场景

加载更多:设置 options.loadMore 支持加载更多的情况

分页和加载原理:在 useAsync 这个基础请求 hook 基础上再包一层 hook ,扩展取数参数与返回结果。

所以,不在此处多余赘述了。

document.visibilityState :表示下面 4 个可能状态的值

hidden :页面在后台标签页中或者浏览器最小化

visible :页面在前台标签页中

prerender :页面在屏幕外执行预渲染处理 document.hidden 的值为 true

unloaded :页面正在从内存中卸载

visibilitychange 事件:当文档从可见变为不可见或者从不可见变为可见时,会触发该事件。

函数返回值只会在组件的初始渲染中起作用,后续渲染时会被忽略

分析:对于同一个实例,可能出现多次调用 _run 方法,导致 this.count 和 currentCount 出现数据不同步的情况,比如,第一次调用 _run 后,刚好执行“关键点 闭包取数”后,还未执行到 return , 又执行了 _run ,导致此时 this.count+=1 ,那么第一次调用 _run.currentCount 的值比当前的 this.count 小1。

作用:保证 state 中的数据是最近一次访问接口得到的数据

源码github地址

用法地址

精读《@umijs/use-request》源码

应用场景: input输入信息进行搜索,如果每敲一个字符就请求后台接口,给后台的压力太大了,所以做好防抖,即让程序只执行最后一次的事件。

为解决该问题,探索到了两个解决方案:

直接使用lodash工具库的debounce方法

参考网址: https://blog.csdn.net/qq_39139322/article/details/103295326

应用场景: 滚轮滚动触发事件频繁,加上延迟可低频触发

看过了上面闭包防抖的写法,下面闭包节流的写法也很好理解了~