如题，防抖不是刚需吗？为啥不默认融入到 onClick 中，或者通过入参控制不行吗？ 开发中每个都加防抖，麻烦死了！！！！
 |
1
shakaraka PRO 😅
|
 |
2
summerwar 1 月 14 日
因为原生的 click 就不防抖
|
 |
3
craftsmanship 1 月 14 日 via Android
你都用 react 了 不知道找个相关库用一下吗
|
 |
4
shaozelin030405 1 月 14 日  2
...不是刚需
|
 |
5
wangtian2020 1 月 14 日
你觉得组件库不合理可以自己去提 issue 提 pr ，我上个月就提了个 issue 解决一个防抖
|
 |
6
iOCZS 1 月 14 日 2
没有网络请求需要啥防抖。。。
|
 |
7
zombiej 1 月 14 日 2
做不做的答案其实很简单，就是你进行调整后，开发者是否还能还原原来的功能以及是否有必要。
比如说 onClick 防抖，那在不防抖的场景里（比如抢票、短时间点击抢积分等等）开发者就需要绕非常大的一圈来实现支持多点击效果。 那是不是可以加一个属性来支持配置？那就看你的库是否贴近底层，越近越受限制，越远越自由。一个 onClick 防抖需要在 Fiber 节点里存储最近点击数据（我们暂时不提 Fiber 本身是一个抽象节点，本来就不应该关心这件事），那对于大量不处理点击事件的节点都是没有意义的数据，但是因为冒泡以及可以存在动态调整 props 来支持 onClick ，导致框架层必须要预存数据。对于性能与内存都是没有必要的。 |
 |
8
phkvae 1 月 14 日 10
这就是你和框架设计者的区别，你看到的只是你的业务问题，框架解决的是更高层面的问题
|
 |
9
shintendo 1 月 14 日
React 的哲学就是手动挡
|
|
10
phkvae 1 月 14 日 1
开发中每个加防抖 你应该想的是去封装一个组件 或者写一个 hooks 是来解决 而不是每个都去加
|
 |
11
NerbraskaGuy 1 月 14 日 1
每个点击单独加防抖那你也是蛮拼的，封装一个通用防抖函数都比来这发帖吐槽更快
|
 |
12
diudiuu 1 月 14 日 4
在你想要的位置加个看不见的遮罩，还抖什么抖。 看见防抖俩字都想吐，抖了个🔨
|
 |
13
HojiOShi 1 月 14 日 23
如果不是为了赚币，我觉得只有会流口水的所谓开发才能问得出这个问题。
|
 |
14
chenliangngng 1 月 14 日
比如我要做个连点器或者计数器怎么办
防抖功能完全可以通过引用第三方包或者手动实现，通过高阶函数传参控制 |
 |
15
nszbf 1 月 14 日
=.=，多小白问出这样的问题
|
 |
16
newaccount 1 月 14 日 2
老哥，前端不适合你，去做后端吧
后端就简单多了 来~ 这是个 apple~ 这是个 pen~ PIA! banana pie! |
 |
18
moooooooo 1 月 14 日
😅
|
 |
19
yhxx 1 月 14 日 2
设计模式第一大原则：单一职责
|
 |
20
zhengfan2016 1 月 14 日
vue 都没有这种功能
|
 |
21
molvqingtai 1 月 14 日
防抖了
还要不要双击选中文本？ 还要不要事件冒泡？ 如果不要冒泡导致全局事件埋点失效怎么处理？ 如果需要冒泡怎么既可以让事件冒泡又能实现防抖效果？ 防抖有那么多配置项，防抖延时是前置还是后置？ 既然都有防抖了要不要支持节流？ 你觉得只是加个防抖，在框架作者看来需要处理一堆问题 |
 |
22
MindMindMax 1 月 14 日
防抖策略呢？ 怎么抽象出相关的参数？ 会不会增加使用难度？
|
 |
23
wogogoing PRO 框架设计需要考虑普遍的通用性，“防抖”可以说是业务层面的事情。
如果框架连这些内容都要事无巨细的处理，那么会背上沉重的技术债，而且也会丢失通用性。 |
 |
24
ramcasky 1 月 14 日
不要只站在自己的角度上去想
|
 |
25
worker201 1 月 14 日
声明一下，lz 是个特例，并不是所有前端都这么纯
|
 |
26
frankies 1 月 14 日
看来前端娱乐圈真的不是个笑话
 |
 |
27
sentinelK 1 月 14 日 1
很多人只嘲讽，不讲逻辑。我尝试讲讲看。
首先，从原教旨主义上讲，事件的触发默认逻辑就是多线程的。既触发几次事件，响应的方法就应该执行几次。所以至少不能默认“防抖”。 其次，“防抖按钮组件”是存在的。只是不是 React 提供的而已。 然后，“防抖按钮”在目前的互联网逻辑下用的多么？多。因为当今远程访问多了，延时大了，不防抖很容易和用户意愿相悖。 最后，React 应该给机制来解决么？不应该。因为 React 解决的，是也仅是“前端的职能管理与分工”问题。不解决业务与 UI 问题。 所以，不是 React 应该包含，而是你应该使用一个带 loading 按钮的 UI 组件库。 回答完毕。 |
 |
28
tog 1 月 14 日
新手吧？
现在老油条了，写个鸡吧的防抖 |
|
29
sentinelK 1 月 14 日
btw:由此就引申出一个问题。目前多数新的 web 应用都上框架，是因为管理职能的需要。
使用框架并不是 web 开发的必要条件。 所以不要啥事儿都往 React 、Vue 、Angular 身上遮。 |
 |
30
66beta 1 月 14 日
喜欢大而全是吧，去用阿里的开源框架吧
 |
 |
31
suyuyu 1 月 14 日 1
我建议你买化为
|
 |
32
swulling 1 月 14 日
我有个问题，如果涉及到后端执行的按钮，按下后状态变成 disabled 等待后端返回，为什么会抖？
|
 |
33
woodytang 1 月 14 日
为啥要防抖，我就是想要抖怎么办
|
 |
34
Leviathann 1 月 14 日
hook 可以抽象任意和状态有关的操作
|
 |
35
AV1 1 月 15 日 2
防抖不是刚需。
而且—— 绝大部分在 onclick 事件上用防抖，是错误的。 防抖是给 oninput 、onmousemove 、onresize 这类高频事件用的。 你要防止重复的异步网络请求，应该是用 disabled 来禁用按钮，待请求成功后再解除禁用。 防抖并不能阻止重复的网络请求。 |
|
37
sentinelK 1 月 15 日
@AV1 "绝大部分在 onclick 事件上用防抖，是错误的。
防抖是给 oninput 、onmousemove 、onresize 这类高频事件用的。" 没懂，onclick 事件和以上的几个事件有什么区别？ 只要是事件就有可能有防抖的业务需求，是否防抖跟是什么事件无关。防抖也不光指处理程序内部的逻辑噪声。 对应的，还有个处理方式叫“节流”。 另外，UI 上的反馈处理和事件上的防抖也并不冲突。UI 变化是人机工效逻辑（用于提示使用者的），事件防抖是业务逻辑（用来防止逻辑错误的）。 |
 |
40
geminy066 1 月 16 日
张三要防抖，李四说要节流，王五说要加延迟，赵六说要加立即执行，七七说要... 那么 React 就炸了。
所以 react 才有各种库... |
Select Language