背景

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

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

并发场景在开发和测试阶段难以排查全面，呈现线上 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 申请完结（胜利 / 失败）才进行对这个申请的拦挡。

具体实现

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

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

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