背景
并发抵触问题
,是日常开发中一个比拟常见的问题。
不同用户在较短时间距离内变更数据,或者某一个用户进行的反复提交操作都可能导致并发抵触。
并发场景在开发和测试阶段难以排查全面,呈现线上 bug 当前定位艰难,因而做好并发管制是前后端开发过程中都须要器重的问题。
对于同一用户短时间内反复提交数据的问题,前端通常能够先做一层拦挡。
本文将探讨前端如何利用 axios 的拦截器过滤反复申请,解决并发抵触。
个别的解决形式 — 每次发申请增加 loading
在尝试 axios 拦截器之前,先看看咱们之前业务是怎么解决并发抵触问题的:
每次用户操作页面上的控件(输入框、按钮等),向后端发送申请的时候,都给页面对应的控件增加 loading 成果,提醒正在进行数据加载,同时也阻止 loading 成果完结前用户持续操作控件。
这是最间接无效的形式,如果你们前端团队成员足够仔细急躁,领有良好的编码习惯,这样就能够解决大部分用户不小心反复提交带来的并发问题了。
更优的解决方案:axios 拦截器对立解决
我的项目中须要前端限度并发的场景这么多,咱们当然要思考更优更省事的计划。
既然是在每次发送申请的时候进行并发管制,那如果能从新封装下发申请的公共函数,对立解决反复申请实现主动拦挡,就能够大大简化咱们的业务代码。
我的项目应用的 axios
库来发送 http
申请,axios
官网为咱们提供了丰盛的 API,咱们来看看拦挡申请须要用到的两个外围 API:
1. interceptors
拦截器包含申请拦截器和响应拦截器,能够在申请发送前或者响应后进行拦挡解决,用法如下:
// 增加申请拦截器
axios.interceptors.request.use(function (config) {
// 在发送申请之前做些什么
return config;
}, function (error) {
// 对申请谬误做些什么
return Promise.reject(error);
});
// 增加响应拦截器
axios.interceptors.response.use(function (response) {
// 对响应数据做点什么
return response;
}, function (error) {
// 对响应谬误做点什么
return Promise.reject(error);
});
2. cancel token
:
调用 cancel token API
能够勾销申请。官网提供了两种形式来构建 cancel token
,咱们采纳这种形式:通过传递一个 executor
函数到 CancelToken
的构造函数来创立 cancel token
,不便在下面的申请拦截器中检测到反复申请能够立刻执行:
const CancelToken = axios.CancelToken;
let cancel;
axios.get('/user/12345', {cancelToken: new CancelToken(function executor(c) {
// executor 函数接管一个 cancel 函数作为参数
cancel = c;
})
});
// cancel the request
cancel();
本文提供的思路就是利用 axios interceptors API
拦挡申请,检测是否有多个雷同的申请同时处于 pending 状态,如果有就调用 cancel token API
勾销反复的申请。
如果用户反复点击按钮,先后提交了 A 和 B 这两个完全相同(思考申请门路、办法、参数)的申请,咱们能够从以下几种拦挡计划中抉择其一:
- 勾销 A 申请,只收回 B 申请
- 勾销 B 申请,只收回 A 申请
- 勾销 B 申请,只收回 A 申请,把收到的 A 申请的返回后果也作为 B 申请的返回后果
第三种计划须要做监听解决减少了复杂性,联合咱们理论的业务需要,最初采纳了第二种计划来实现,即:
只发第一个申请。在 A 申请还处于 pending 状态时,后发的所有与 A 反复的申请都勾销,理论只收回 A 申请,直到 A 申请完结(胜利 / 失败)才进行对这个申请的拦挡。
具体实现
- 存储所有 pending 状态的申请
首先咱们要将我的项目中所有的 pending 状态的申请存储在一个变量中,叫它 pendingRequests
,
能够通过把 axios
封装为一个单例模式的类,或者定义全局变量,来保障 pendingRequests
变量在每次发送申请前都能够拜访,并查看是否为反复的申请。
let pendingRequests = new Map()
把每个申请的办法、url 和参数组合成一个字符串,作为标识该申请的惟一 key,同时也是 pendingRequests
对象的 key:
const requestKey = `${config.url}/${JSON.stringify(config.params)}/${JSON.stringify(config.data)}&request_type=${config.method}`;
帮忙了解的小 tips:
- 定义
pendingRequests
为 map 对象的目标是为了不便咱们查问它是否蕴含某个 key,以及增加和删除 key。增加 key 时,对应的 value 能够设置用户自定义的一些性能参数,前面扩大性能的时候会用到。 config
是axios
拦截器中的参数,蕴含以后申请的信息
-
在申请收回前查看以后申请是否反复
在申请拦截器中,生成下面的
requestKey
,查看pendingRequests
对象中是否蕴含以后申请的requestKey
- 有:阐明是反复的申请,cancel 掉以后申请
- 没有:把
requestKey
增加到pendingRequests
对象中
因为前面的响应拦截器中还要用到以后申请的 requestKey
,为了防止踩坑,最好不要再次生成,在这一步就把 requestKey
存回 axios
拦截器的 config
参数中,前面能够间接在响应拦截器中通过 response.config.requestKey
取到。
代码示例:
// 申请拦截器
axios.interceptors.request.use((config) => {if (pendingRequests.has(requestKey)) {config.cancelToken = new axios.CancelToken((cancel) => {
// cancel 函数的参数会作为 promise 的 error 被捕捉
cancel(` 反复的申请被被动拦挡: ${requestKey}`);
});
} else {pendingRequests.set(requestKey, config);
config.requestKey = requestKey;
}
return config;
},
(error) => {
// 这里呈现谬误可能是网络稳定造成的,清空 pendingRequests 对象
pendingRequests.clear();
return Promise.reject(error);
}
);
- 在申请返回后保护
pendingRequests
对象
如果申请顺利走到了响应拦截器这一步,阐明这个申请曾经完结了 pending 状态,那咱们要把它从 pendingRequests
中除名:
axios.interceptors.response.use((response) => {
const requestKey = response.config.requestKey;
pendingRequests.delete(requestKey);
return Promise.resolve(response);
}, (error) => {if (axios.isCancel(error)) {console.warn(error);
return Promise.reject(error);
}
pendingRequests.clear();
return Promise.reject(error);
})
- 须要清空
pendingRequests
对象的场景
遇到网络稳定或者超时等状况造成申请谬误时,须要清空原来存储的所有 pending 状态的申请记录,在下面演示的代码曾经作了正文阐明。
此外,页面切换时也须要清空之前缓存的 pendingRequests
对象,能够利用 Vue Router
的 beforeEach
钩子:
router.beforeEach((to, from, next) => {request.clearRequestList();
next();});
性能扩大
- 对立解决接口报错提醒
与后端约定好接口返回数据的格局,对接口报错的状况,能够对立在响应拦截器中增加 toast 给用户提醒,
对于非凡的不须要报错的接口,能够设置一个参数存入 axios
拦截器的 config
参数中,过滤掉报错提醒:
// 接口返回 retcode 不为 0 时须要报错,申请设置了 noError 为 true 则这个接口不报错
if (
response.data.retcode &&
!response.config.noError
) {if (response.data.message) {
Vue.prototype.$message({
showClose: true,
message: response.data.message,
type: 'error',
});
}
return Promise.reject(response.data);
}
- 发送申请时给控件增加 loading 成果
下面利用 axios interceptors
过滤反复申请时,能够在控制台抛出信息给开发者提醒,在这个根底上如果能给页面上操作的控件增加 loading 成果就会对用户更敌对。
常见的 ui 组件库都有提供 loading 服务,能够指定页面上须要增加 loading 成果的控件。上面是以 element UI
为例的示例代码:
// 给 loadingTarget 对应的控件增加 loading 成果,贮存 loadingService 实例
addLoading(config) {if (!document.querySelector(config.loadingTarget)) return;
config.loadingService = Loading.service({target: config.loadingTarget,});
}
// 调用 loadingService 实例的 close 办法敞开对应元素的 loading 成果
closeLoading(config) {config.loadingService && config.loadingService.close();
}
与下面过滤报错形式相似,发申请的时候将元素的 class name 或 id 存入 axios
拦截器的 config
参数中,
在申请拦截器中调用 addLoading
办法, 响应拦截器中调用 closeLoading
办法,就能够实现在申请 pending 过程中指定控件(如 button)loading,申请完结后控件主动勾销 loading 成果。
- 反对多个拦截器组合应用
简略看下 axios interceptors
局部实现源码能够了解,它反对定义多个 interceptors
,所以只有咱们定义的 interceptors
合乎 Promise.then
链式调用的标准,还能够增加更多功能:
this.interceptors.request.forEach(function unshiftRequestInterceptors(interceptor) {chain.unshift(interceptor.fulfilled, interceptor.rejected);
});
this.interceptors.response.forEach(function pushResponseInterceptors(interceptor) {chain.push(interceptor.fulfilled, interceptor.rejected);
});
while (chain.length) {promise = promise.then(chain.shift(), chain.shift());
}
总结
并发问题很常见,解决起来又绝对繁琐,前端解决并发抵触时,能够利用 axios
拦截器对立解决反复申请,简化业务代码。
同时 axios
拦截器反对更多利用,本文提供了局部罕用扩大性能的实现,感兴趣的同学能够持续开掘补充拦截器的其余用法。
明天的内容就这么多,心愿对你有帮忙。
如果感觉内容有帮忙,能够关注下我的公众号,把握最新动静,一起学习!