背景

并发抵触问题， 是日常开发中一个比拟常见的问题。

不同用户在较短时间距离内变更数据，或者某一个用户进行的反复提交操作都可能导致并发抵触。

并发场景在开发和测试阶段难以排查全面，呈现线上 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 requestcancel();

本文提供的思路就是利用 axios interceptors API 拦挡申请，检测是否有多个雷同的申请同时处于 pending 状态，如果有就调用 cancel token API 勾销反复的申请。

如果用户反复点击按钮，先后提交了 A 和 B 这两个完全相同（思考申请门路、办法、参数）的申请，咱们能够从以下几种拦挡计划中抉择其一：

  • 勾销 A 申请，只收回 B 申请
  • 勾销 B 申请，只收回 A 申请
  • 勾销 B 申请，只收回 A 申请，把收到的 A 申请的返回后果也作为 B 申请的返回后果

第三种计划须要做监听解决减少了复杂性，联合咱们理论的业务需要，最初采纳了第二种计划来实现，即：

只发第一个申请。在 A 申请还处于 pending 状态时，后发的所有与 A 反复的申请都勾销，理论只收回 A 申请，直到 A 申请完结（胜利/失败）才进行对这个申请的拦挡。

具体实现

  1. 存储所有 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 拦截器中的参数，蕴含以后申请的信息

  1. 在申请收回前查看以后申请是否反复

    在申请拦截器中，生成下面的 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);  });
  1. 在申请返回后保护 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);})
  1. 须要清空 pendingRequests 对象的场景

遇到网络稳定或者超时等状况造成申请谬误时，须要清空原来存储的所有 pending 状态的申请记录，在下面演示的代码曾经作了正文阐明。

此外，页面切换时也须要清空之前缓存的 pendingRequests 对象，能够利用 Vue Router 的 beforeEach 钩子：

router.beforeEach((to, from, next) => {  request.clearRequestList();  next();});

性能扩大

  1. 对立解决接口报错提醒

与后端约定好接口返回数据的格局，对接口报错的状况，能够对立在响应拦截器中增加 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);}
  1. 发送申请时给控件增加 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 成果。

  1. 反对多个拦截器组合应用

简略看下 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 拦截器反对更多利用，本文提供了局部罕用扩大性能的实现，感兴趣的同学能够持续开掘补充拦截器的其余用法。

明天的内容就这么多，心愿对你有帮忙。

如果感觉内容有帮忙， 能够关注下我的公众号，把握最新动静，一起学习！