qrobot

@ragnaroks 因为长期在前端工作中, 我把 throttle 局限为 lodash.throttle 这样的方法, 这非常抱歉.

一个请求大概会有 发送(send), 接受(receive), 重试(retry), 这三个阶段, 在 throttle 中并不是很优雅的对这三个阶段中进行很好的操作

@ragnaroks 你可以在 Google, Facebook, Github 等产品中去学习一下, 看看在防止多次点击的情况下, 他们是否会使用 throttle 做优化处理, 或则你看在好的虚拟滚动的解决方案中, 是否经常采用 throttle 来作为解决方案, 确实 throttle 很方便, 但是我认为它并不是好的解决方案, 我甚至认为, 这在某种场景下, 是一个滥用的行为(非常错误的行为)

@ragnaroks 我跟你讲一下 throttle 也就是节流, 指的是在指定的间隔中指执行一次. 你说了,我可能在这方面没有经验.

请回答我两个问题


1. throttle 间隔时间多少合适?
2. throttle 会导致当前队列中所有的消息都处理完毕之后才能执行, 在特定的情况下, 我希望立即执行此函数应该怎么办?
3. 如果请求在 throttle 间隔时间中失效了, 我是否要等待 throttle 间隔结束?

当你回答了我的这三个问题, 请问 `throttle 从来不是"非常错误的行为"` 你还保持此观念吗?

你可以看我的 github 里面的所有方案, 我从来不会采用 throttle ,这种方式进行所谓防止多次触发.



在回答你之后的一个问题, 如果在 在没有异步完成端口之前，F5 就能刷死服务器, 很显然, 这个服务器的后端代码存在严重的问题, 前端的防止多次点击, 本质来说是为了给客户进行一个良好的视觉反馈, 而并不是为了保证请求到后端的接口一定就是一次.

因为恶意用户完全可以通过其他方式进行多次发送请求.

@qrobot 用户多次点击的原因其实很简单

1. 设备原因导致误触
2. 点击提交后, 没有反馈,以为网络延迟.

@ragnaroks 首先 throttle 是一件非常错误的行为, 因为 throttle 的实现就是 setTimeout , 这个在 JS 的线程模型中, 部分场景中会有非常不可思议的结果, 其次 throttle 多少毫秒合适? 600 毫秒? 1000 毫秒? 比如点击了,没有反馈, 就算间隔 5 秒,用户也会进行不断的点击, throttle 无疑就是一种非常错误的设计, 也是非常错误的解决方案.


相对于 throttle 来说, 按钮上的 loading 或者 按钮上的 禁用 都是一个非常好的方案,

@cmdOptionKana 如果是这样, 那真的感觉好无趣, 就像你游戏通关以后在也没有第一次初见这个游戏的感觉了

理性分析, 有可能是你公司附近买的早餐有问题, 或者公司的零食以及水有问题,导致你会拉肚子

我不理解, 也不明白,但似乎好像幸福也许和物资条件没有必然的联系?