对fetch timeout的思考 - CNode技术社区

对fetch timeout的思考
发布于 8 年前 作者 fruit-memory 8270 次浏览 来自 分享

起因

我在网上看到很多关于fetch timeout的封装,但是我觉得是伪timeout,只是抛错,但是fetch的Promise链会一直执行下去

Promise.race([
 fetch('/api')
 .then(res => res.json())
 .then(res => console.log(555)),
 new Promise(function(resolve, reject) {
 setTimeout(() => {
 reject(new Error('request timeout'));
 console.log(111);
 }, 100);
 })
]);

结果: image.png 可以看到就算超时后,fetch请求仍按正常顺序执行,输出了555,超时一般会重新请求,这样到最后就有可能输出2次或者多次555,试想如果你在then函数里面执行setState操作,这样视图就会更新2次或者多次,这样显然不是我们想要的结果,我们想要的是获取结果后执行一次

针对以上缺点进行改进

于是我封装以下代码,支持timeout(我这个其实也是伪timeout,没办法,除非使用xhr,但是超时后Promise链只会执行报错,因为结果和报错使用同一个Promise)和重新请求,由于返回值是一个Promise,用法和fetch保持一致 支持Promise.all,.race方法

代码地址

class TimeoutError extends Error {
 constructor(message) {
 super(message);
 this.name = 'TimeoutError';
 }
}
/**
 * 提供参数校验和wrapper功能
 *
 * @param {*} url
 * @param {*} [options={ method: 'GET' }]
 * @returns {Promise} the request result
 */
function request(url, options = { method: 'GET' }) {
 let retryCount = 0;
 let parseJSON = response => {
 return response.json();
 };
 let checkStatus = response => {
 if (response.status >= 200 && response.status < 300) {
 return response;
 }
 let error = new Error(response.statusText);
 error.response = response;
 throw error;
 };
 class Request {
 constructor(url, { retry, timeout, ...options }) {
 this.url = url;
 this.retry = retry || 0;
 this.timeout = timeout || 10000;
 this.options = options;
 }
 then(fn) {
 let done = false;
 setTimeout(() => {
 // 无论是请求重试还是最终超时错误,此次请求得到的结果作废
 if (retryCount < this.retry && !done) {
 done = true;
 retryCount++;
 this.then(fn);
 } else {
 let error = new TimeoutError(`timeout of ${this.timeout}ms execeeded`);
 this.catchError(error);
 }
 }, this.timeout);
 fetch(this.url, this.options)
 .then(checkStatus)
 .then(parseJSON)
 .then(res => {
 // 未进入重试或者超时错误,返回结果
 if (!done) {
 fn(res);
 done = true;
 }
 })
 .catch(err => {
 this.catchError(err);
 });
 return this;
 }
 catch(fn) {
 this.catchError = fn;
 }
 }
 return new Promise((resolve, reject) =>
 new Request(url, options).then(res => resolve(res)).catch(err => reject(err))
 );
}
request('/api', {
 retry: 2,
 timeout: 1000
}).then(res => console.log(res))

使用封装后的fetch进行请求

设置Cache-Control:2s和timeout:1000ms后的请求情况 可以看到1.49s后请求才完全响应,而我们设置了1s重新请求,所以第二次请求由于上次请求缓存未失效的原因,在1.49s的时候利用了上次请求作为结果进行了响应 设置缓存,第一次超时请求结果作废(then函数不执行),第二次请求直接拿了第一次的缓存,这样减少了请求响应时间还减轻了服务器的压力 image.png image.png


image.png image.png 不设置缓存,如果网络那段时间不太好,第三次请求才顺利拿到结果,也有可能第二次拿到请求,抑或是重试2次以后还是超时了 image.png image.png

请求重试最好跟cache-control配合使用,这样当前面请求超时结果作废后,第二次请求会等到第一次请求结果的返回,前提是缓存没有失效 缓存失效时间是从响应开始时计算的,一般配合超时重新请求的话,timeout设置为正常响应的1.5倍,max-age应该设置为timeout的1.5+倍(或者为timeout的2倍,方便利用上次响应结果),具体数值需要根据具体情况合理设置

可能最后会有人有这样的疑问,你使用缓存,即上一次请求超时响应的结果,那还不如Promise.race的方法简单,一样的效果 使用缓存的优势就是如果第一次超时响应的时间短于timeout加正常响应甚至又一次超时的时间,而且缓存没有失效,那么既节省了时间又节省了服务器的压力,假如失效了呢?重新请求呗!不管怎样,利用缓存绝对是比不利用的好

最后,如果你觉得这篇文章对你有用的话,麻烦给个小星星,如有错误的话,也欢迎指正

9 回复

我在网上看到很多关于fetch timeout的封装,但是我觉得是伪timeout,只是抛错,但是fetch的Promise链会一直执行下去

放一张我在浏览器里测试的图,和你的结果不太一致

15289395257368_0.jpg

我觉得你说的的有问题,请求超时是promise.racez这个promise变为reject,并不代表数组里同级的异步就要变了。promise.race的结果和时间最短的结果一样,数组里其他promise和时间最短的promise没有依赖关系

@xiaozhouge 没错啊。我也没说他们之前有依赖关系吧

@wangchaoduo 这是因为fetch失败抛错了,我没写catch,所以不会报错,你如果请求一个可以正常返回结果的接口,结果就和我这个是一样的了 image.png

@fruit-memory sorry,我理解错你的起因了

HTML规范已经加了 AbortController,应该很快大部分浏览器都支持了,如果用 AbortController 就可以真正 abort 了:

function request(url, { retry = 3, timeout = 10000, ...options }) {
 let count = 0;
 function doRequest() {
 const controller = new AbortController();
 const signal = controller.signal;
 const timer = setTimeout(() => controller.abort(), timeout);
 return fetch(url, { ...options, signal })
 .then(res => {
 clearTimeout(timer);
 return res.json();
 })
 .catch(e => {
 count++;
 if (count === retry) {
 return Promise.reject(e);
 }
 return doRequest();
 });
 }
 
 return doRequest();
}
request('/api', { retry: 2, timeout: 1000 });

目前可以用这个 fetch 的 polyfill:https://github.com/Netflix/yetch

@helloyou2012 我去mdn看了下兼容性。。。chrome66才开始支持,能用的话,等个一两年,而且,ie11也不支持,这玩意太新了,要是全部支持那就爽了

回到顶部

AltStyle によって変換されたページ (->オリジナル) /