用节流做防抖合适么

[wukongkong]

项目里面，如果直接用防抖，那么按钮的执行其实被延迟了，想更好的用户体验，思路是立即响应用户的操作，然后屏蔽后续 200ms 的点击。

自定义的节流函数，对 promise 函数做了锁的操作，等待 promise 执行完毕，才会再次触发，

老铁们，我这样的想法对么，还是说防抖只能是推迟按钮的实际点击执行比较合适。

[xiaoming1992]

lodash debounce 可以设置 leading trailing 的呀

[wukongkong]

@xiaoming1992 其实不合适，比如说 下面是 ajax 请求，设置的防抖事件是 200ms，ajax 300ms，这时候 ajax 可以被重复触发。

我感觉我的方案可能更类似于，按钮的 disabled 状态

[hackyuan]

建议看一下节流、防抖的定义，自然就选择了适合的

[UnitTest]

没记错的话, lodash 里的 debounce 和 throttle 底层是同样的方法.
你说的这个情况我觉得就是节流而不是防抖.
防抖的一个典型场景就是拉伸窗口, 最后的状态是一定要拿到的, 如果节流的话, 拿到的窗口尺寸是有问题的.

如果这个按钮有请求后台的话, 那么等 promise 返回请求结束之后才允许点击是正常的做法, 这其实也和 throttle 没关系.

[wukongkong]

@UnitTest 哥，一般项目里面你们按钮是怎么处理防抖节流的呢。

我理解，我这里其实正常的防抖节流都说的通

但是，我更倾向于使用节流，给用户一个立即的反馈。而不是去执行最后一个点击操作。

[xiaoming1992]

@wukongkong #2 这是另一个条件啊，promise 期间加一个 disable 就可以了，觉得不应该放到防抖节流里面

[xiaoming1992]

@UnitTest #4 在密集触发的情况下，防抖 debounce 时中间不会调用，只在最后一次触发后延时调用，节流 throttle 是中间每隔固定间隔会调用。两者都可以选择 trailing，所以节流拿到的窗口尺寸也不会有问题。

个人觉得更好的例子是 input onchange 时往后端发请求，防抖就很合适，用户密集输入时不需要请求，等用户停顿下来后再请求。至于 resize，看项目要求，需不需要在用户密集 resize 期间（拉来拉去时）获取窗口尺寸，如果需要，就用节流，如果只需要在用户停顿的时候再获取窗口尺寸，就可以用防抖了

[UnitTest]

@xiaoming1992 你说的是对的, 我这个例子确实有问题, 早上刚起床没想明白...