怎样防止重复发送 Ajax 请求?
著作权归作者所有。
商业转载请联系作者获得授权,非商业转载请注明出处。
作者:长天之云
链接:http://www.zhihu.com/question/19805411/answer/15465427
来源:知乎
商业转载请联系作者获得授权,非商业转载请注明出处。
作者:长天之云
链接:http://www.zhihu.com/question/19805411/answer/15465427
来源:知乎
不推荐用外部变量锁定或修改按钮状态的方式,因为那样比较难:
我推荐用主动查询状态的方式(A、B,jQuery 为例)或工具函数的方式(C、D)来去除重复操作,并提供一些例子作为参考:
A. 独占型提交
只允许同时存在一次提交操作,并且直到本次提交完成才能进行下一次提交。
B. 贪婪型提交
无限制的提交,但是以最后一次操作为准;亦即需要尽快给出最后一次操作的反馈,而前面的操作结果并不重要。
比如某些应用的条目中,有一些进行类似「喜欢」或「不喜欢」操作的二态按钮。如果按下后不立即给出反馈,用户的目光焦点就可能在那个按钮上停顿许久;如果按下时即时切换按钮的状态,再在程序上用 abort 来实现积极的提交,这样既能提高用户体验,还能降低服务器压力,皆大欢喜。
C. 节制型提交
无论提交如何频繁,任意两次有效提交的间隔时间必定会大于或等于某一时间间隔;即以一定频率提交。
如果客户发送每隔100毫秒发送过来10次请求,此模块将只接收其中6个(每个在时间线上距离为150毫秒)进行处理。
这也是解决查询冲突的一种可选手段,比如以知乎草稿举例,仔细观察可以发现:
编辑器的 blur 事件会立即触发保存;
保存按钮的 click 事件也会立即触发保存;
但是存在一种情况会使这两个事件在数毫秒内连续发生——当焦点在编辑器内部,并且直接去点击保存按钮——这时用 throttle 来处理是可行的。
另外还有一些事件处理会很频繁地使用 throttle,如: resize、scroll、mousemove。
D. 懒惰型提交
任意两次提交的间隔时间,必须大于一个指定时间,才会促成有效提交;即不给休息不干活。
还是以知乎草稿举例,当在编辑器内按下 ctrl + s 时,可以手动保存草稿;如果你连按,程序会表示不理解为什么你要连按,只有等你放弃连按,它才会继续。
============
更多记忆中的例子
方式 C 和 方式 D 有时更加通用,比如这些情况:
而方式 C 甚至可以和方式 B 组合使用,比如自动完成组件(Google 首页的搜索就是):
----- update 2013-01-08 -----
E. 记忆型
对于同样的参数,其返回始终结果是恒等的——每次都将返回同一对象。
应用例子有编辑器,如粘贴内容时抓取其中的链接信息,memoize 用以保证同样的链接不会抓取两次。
----- update 2013-03-27 -----
F. 累积型
前几天处理自动完成事件时得到这个函数,发现也可以用在处理连续事件上,它能够把连续的多次提交合并为一个提交,比如:
样例实现:
----- update 2013-04-16 -----
另一种累积是按时间而不是次数,比如应用在行为统计上,可能在瞬间收集到数十上百类似的行为,这时可以用上面 pile 的结构加上 debounce 来防止大批重复请求(但又不丢失任何统计):
G. 采样型
这是最近重构时联想到的,一种和上面都不同的去重操作,可以应用在自动加载(timeline)行为控制上:
如果 sample 是固化的选择函数(n 选 1),它这实际上会这样工作:
但「自动加载」的应用可能想要的是(两次自动,一次手动):
对于这种情况,可以定义作为配置的选择函数来实现控制:
即每个下一次加载完成之后, 每三次有两次对下一次加载实行自动加载。
- 要考虑并理解 success, complete, error, timeout 这些事件的区别,并注册正确的事件,一旦失误,功能将不再可用;
- 不可避免地比普通流程要要多注册一个 complete 事件;
- 恢复状态的代码很容易和不相干的代码混合在一起;
我推荐用主动查询状态的方式(A、B,jQuery 为例)或工具函数的方式(C、D)来去除重复操作,并提供一些例子作为参考:
A. 独占型提交
只允许同时存在一次提交操作,并且直到本次提交完成才能进行下一次提交。
module.submit = function() {
if (this.promise_.state() === 'pending') {
return
}
return this.promise_ = $.post('/api/save')
}
B. 贪婪型提交
无限制的提交,但是以最后一次操作为准;亦即需要尽快给出最后一次操作的反馈,而前面的操作结果并不重要。
module.submit = function() {
if (this.promise_.state() === 'pending') {
this.promise_.abort()
}
// todo
}
C. 节制型提交
无论提交如何频繁,任意两次有效提交的间隔时间必定会大于或等于某一时间间隔;即以一定频率提交。
module.submit = throttle(150, function() {
// todo
})
这也是解决查询冲突的一种可选手段,比如以知乎草稿举例,仔细观察可以发现:
编辑器的 blur 事件会立即触发保存;
保存按钮的 click 事件也会立即触发保存;
但是存在一种情况会使这两个事件在数毫秒内连续发生——当焦点在编辑器内部,并且直接去点击保存按钮——这时用 throttle 来处理是可行的。
另外还有一些事件处理会很频繁地使用 throttle,如: resize、scroll、mousemove。
D. 懒惰型提交
任意两次提交的间隔时间,必须大于一个指定时间,才会促成有效提交;即不给休息不干活。
module.submit = debounce(150, function() {
// todo
})
============
更多记忆中的例子
方式 C 和 方式 D 有时更加通用,比如这些情况:
- 游戏中你捡到一把威力强大的高速武器,为了防止你的子弹在屏幕上打成一条直线,可以 throttle 来控制频率;
- 在弹幕型游戏里,为了防止你把射击键夹住来进行无脑游戏,可以用 debounce 来控制频率;
- 在编译任务里,守护进程监视了某一文件夹里所有的文件(如任一文件的改变都可以触发重新编译,一次执行就需要2秒),但某种操作能够瞬间造成大量文件改变(如 git checkout),这时一个简单的 debounce 可以使编译任务只执行一次。
而方式 C 甚至可以和方式 B 组合使用,比如自动完成组件(Google 首页的搜索就是):
- 当用户快速输入文本时(特别是打字能手),可以 throttle keypress 事件处理函数,以指定时间间隔来提取文本域的值,然后立即进行新的查询;
- 当新的查询需要发送,但上一个查询还没返回结果时,可以 abort 未完成的查询,并立即发送新查询;
----- update 2013-01-08 -----
E. 记忆型
var scrape = memoize(function(url) {
return $.post('/scraper', { 'url': url })
})
应用例子有编辑器,如粘贴内容时抓取其中的链接信息,memoize 用以保证同样的链接不会抓取两次。
----- update 2013-03-27 -----
F. 累积型
前几天处理自动完成事件时得到这个函数,发现也可以用在处理连续事件上,它能够把连续的多次提交合并为一个提交,比如:
var request = makePile(5, function() {
$.post('/', { list: JSON.stringify([].slice.call(arguments)) })
})
// 连续发送五次
request({a:1}), request({a:2}), request({a:3}), request({a:4}), request({a:5})
/* post =>
list:[{"a":1},{"a":2},{"a":3},{"a":4},{"a":5}]
*/
var makePile = function(count, onfilter, onvalue) {
var values = [], id = function(value) { return value }
return function(value) {
values.push((onvalue || id).apply(this, arguments))
if (values.length === count) {
onfilter.apply(this, values)
values = []
}
}
}
----- update 2013-04-16 -----
另一种累积是按时间而不是次数,比如应用在行为统计上,可能在瞬间收集到数十上百类似的行为,这时可以用上面 pile 的结构加上 debounce 来防止大批重复请求(但又不丢失任何统计):
var trackFactory = function(delay, action) {
var params = [], slice = [].slice
var touch = debounce(delay, function() {
if (params.length) {
action(params)
params = []
}
})
return function() {
params.push(slice.call(arguments))
touch()
}
}
var track = trackFactory(550, function(params) {
// send tracking request
})
G. 采样型
这是最近重构时联想到的,一种和上面都不同的去重操作,可以应用在自动加载(timeline)行为控制上:
autoload.listen(feeds, 'next', sample(3, function() {
this.enable()
}))
如果 sample 是固化的选择函数(n 选 1),它这实际上会这样工作:
O-O-X-O-O-X
但「自动加载」的应用可能想要的是(两次自动,一次手动):
X-X-O-X-X-O
对于这种情况,可以定义作为配置的选择函数来实现控制:
options { sample: (n) => n % 3 !== 0 }
编辑于 2013-04-16 31 条评论 感谢
收藏 • 没有帮助 •
• 作者保留权利
我的经验的做法是,封装自己的Ajax请求对象.不使用直接使用系统的或者其他第三方的包装.有了自己的封装之后,并不是简单abort就是最好的.我这里会根据实际的情况做处理:1. 所有的Ajax请求都是异步的,我的封装中做一个100毫秒的setTimeout延时.这样就可以有效… 显示全部
我的经验的做法是,封装自己的Ajax请求对象.不使用直接使用系统的或者其他第三方的包装.
有了自己的封装之后,并不是简单abort就是最好的.
我这里会根据实际的情况做处理:
1. 所有的Ajax请求都是异步的,我的封装中做一个100毫秒的setTimeout延时.这样就可以有效的解决用户快速重复点击的问题. 足够快的时候,前一请求并没有真正的发出来.就被clearTimeout清除掉了. abort掉Ajax的请求也会有服务端响应,需要消耗资源.
2.如果用户的操作不并足够快.比如点了保存按钮,在服务器没有返回成功的时候,再次点了保存按钮.(事实上两次请求是一样的.而我们更希望第一次的请求是有效的,第二次的可以不做处理).
在封装中,我们检查传入ajax的请url及参数是否一致,如果一致.则第二次的AJAX并不发出.
3.最后一种情况,两次相间的请求是不同的请求,比如楼上说快速切换Tab的例子.无法,只能abort掉前一个Ajax请求了.
再补充一点,统一的Ajax封装有许多特别的好处:
1.可以计数pending中的请求数,显示当前还有几个请求进行中(我们原来的系统中有一个这样的需求,一般系统也会有比如显示loading的需求...)
2.可以有统一的异常处理,发送的请求失败了(服务器可以返回统一的格式,客户端做集中处理,弹出错框等,或者如firebug那样,把所有的异常放到一个统一的地方去.或者调试阶段增加处理.)
3.如果有大量的小请求,比如取某个表单的下拉列表.一堆下拉框的话.可以在客户端做请求合并.batching Ajax, 这个是从DWR中获得的灵感.
有了自己的封装之后,并不是简单abort就是最好的.
我这里会根据实际的情况做处理:
1. 所有的Ajax请求都是异步的,我的封装中做一个100毫秒的setTimeout延时.这样就可以有效的解决用户快速重复点击的问题. 足够快的时候,前一请求并没有真正的发出来.就被clearTimeout清除掉了. abort掉Ajax的请求也会有服务端响应,需要消耗资源.
2.如果用户的操作不并足够快.比如点了保存按钮,在服务器没有返回成功的时候,再次点了保存按钮.(事实上两次请求是一样的.而我们更希望第一次的请求是有效的,第二次的可以不做处理).
在封装中,我们检查传入ajax的请url及参数是否一致,如果一致.则第二次的AJAX并不发出.
3.最后一种情况,两次相间的请求是不同的请求,比如楼上说快速切换Tab的例子.无法,只能abort掉前一个Ajax请求了.
再补充一点,统一的Ajax封装有许多特别的好处:
1.可以计数pending中的请求数,显示当前还有几个请求进行中(我们原来的系统中有一个这样的需求,一般系统也会有比如显示loading的需求...)
2.可以有统一的异常处理,发送的请求失败了(服务器可以返回统一的格式,客户端做集中处理,弹出错框等,或者如firebug那样,把所有的异常放到一个统一的地方去.或者调试阶段增加处理.)
3.如果有大量的小请求,比如取某个表单的下拉列表.一堆下拉框的话.可以在客户端做请求合并.batching Ajax, 这个是从DWR中获得的灵感.
如果用jquery的话,jquery的ajax提供ajaxPrefilter方法对ajax请求进行拦截,可以在公用的js里配置上1个公用的ajaxPrefilter。全局维护1个request的列表,在ajaxPrefilter中判断要发送的请求是否已经存在,如不存在则发送并将发送中的请求存储到本地,同时覆…
显示全部
如果用jquery的话,jquery的ajax提供ajaxPrefilter方法对ajax请求进行拦截,可以在公用的js里配置上1个公用的ajaxPrefilter。全局维护1个request的列表,在ajaxPrefilter中判断要发送的请求是否已经存在,如不存在则发送并将发送中的请求存储到本地,同时覆盖掉传进来的options下的complete属性,在里面包裹上请求完成后踢出队列的处理。
其它框架的话用类似的方式处理,基本思想就是对原始提供的全局ajax方法进行简单包装下即可。
以上是sample code。
几个地方都可以定制:
其它框架的话用类似的方式处理,基本思想就是对原始提供的全局ajax方法进行简单包装下即可。
// 所有ajax请求的通用前置filter
$.ajaxPrefilter(function( options, originalOptions, jqXHR ) {
// 不重复发送相同请求
var key = generatePendingRequestKey(options);
if (!pendingRequests[key]) {
storePendingRequest(key, jqXHR);
} else {
// or do other
jqXHR.abort();
}
var complete = options.complete;
options.complete = function(jqXHR, textStatus) {
// clear from pending requests
pendingRequests[jqXHR.pendingRequestKey] = null;
if ($.isFunction(complete)) {
complete.apply(this, arguments);
}
};
});
以上是sample code。
几个地方都可以定制:
- 如何算同1个请求
- 遇到发送相同请求的具体处理,可以选择abort之前的,也可以直接abort掉后发的,完全取决于业务需求
知呼上的一篇文章不错:http://www.zhihu.com/question/19805411