这是一个创建于 1150 天前的主题，其中的信息可能已经有所发展或是发生改变。
项目里面，如果直接用防抖，那么按钮的执行其实被延迟了，想更好的用户体验，思路是立即响应用户的操作，然后屏蔽后续 200ms 的点击。
自定义的节流函数，对 promise 函数做了锁的操作，等待 promise 执行完毕，才会再次触发，
老铁们，我这样的想法对么，还是说防抖只能是推迟按钮的实际点击执行比较合适。
 |
1
xiaoming1992 2021-09-12 07:31:31 +08:00 via Android
lodash debounce 可以设置 leading trailing 的呀
|
 |
2
wukongkong OP @xiaoming1992 其实不合适，比如说 下面是 ajax 请求，设置的防抖事件是 200ms，ajax 300ms，这时候 ajax 可以被重复触发。
我感觉我的方案可能更类似于，按钮的 disabled 状态 |
 |
3
hackyuan 2021-09-12 08:03:29 +08:00
建议看一下节流、防抖的定义，自然就选择了适合的
|
 |
4
UnitTest 2021-09-12 09:27:38 +08:00  1
没记错的话, lodash 里的 debounce 和 throttle 底层是同样的方法.
你说的这个情况我觉得就是节流而不是防抖. 防抖的一个典型场景就是拉伸窗口, 最后的状态是一定要拿到的, 如果节流的话, 拿到的窗口尺寸是有问题的. 如果这个按钮有请求后台的话, 那么等 promise 返回请求结束之后才允许点击是正常的做法, 这其实也和 throttle 没关系. |
|
5
wukongkong OP |
|
6
xiaoming1992 2021-09-12 13:06:07 +08:00 via Android
@wukongkong #2 这是另一个条件啊，promise 期间加一个 disable 就可以了，觉得不应该放到防抖节流里面
|
|
7
xiaoming1992 2021-09-12 13:21:37 +08:00 via Android
@UnitTest #4 在密集触发的情况下，防抖 debounce 时中间不会调用，只在最后一次触发后延时调用，节流 throttle 是中间每隔固定间隔会调用。两者都可以选择 trailing，所以节流拿到的窗口尺寸也不会有问题。
个人觉得更好的例子是 input onchange 时往后端发请求，防抖就很合适，用户密集输入时不需要请求，等用户停顿下来后再请求。至于 resize，看项目要求，需不需要在用户密集 resize 期间（拉来拉去时）获取窗口尺寸，如果需要，就用节流，如果只需要在用户停顿的时候再获取窗口尺寸，就可以用防抖了 |
|
8
UnitTest 2021-09-12 17:59:40 +08:00
@xiaoming1992 你说的是对的, 我这个例子确实有问题, 早上刚起床没想明白...
|
Select Language