乐趣区

关于前端:Axios-源码解读-网络请求篇

jiezi

上一章咱们介绍了 Axios 源码解读 —— request 篇，这一章咱们来介绍 Axios 理论发动网络申请的局部吧，也就是 dispatchRequest 办法。

dispatchRequest

这个办法定义也比较简单（如下图）

第 29 行 —— 勾销申请

咱们来逐行解析每一行代码所做的事件吧，首先是第 29 行的勾销申请。（如下）

throwIfCancellationRequested(config);

这个动作不仅仅在发动正式申请前做了一次，而且在申请胜利和申请失败时都做了一次。

只有是被 cancel 的申请，都是不会进入到胜利或失败回调解决中的。（如下图）

而 throwIfCancellationRequested 函数所做的事件，就是检测该申请是否被勾销，如果被勾销则抛出一个谬误，并阻止代码持续向下执行。（如下）

function throwIfCancellationRequested(config) {if (config.cancelToken) {
    // 检测申请是否被勾销，而后决定是否抛出谬误
    config.cancelToken.throwIfRequested();}

  if (config.signal && config.signal.aborted) {
    // 抛出谬误
    throw new Cancel('canceled');
  }
}

当然，整套 CancelToken 的实现还是有一些简单的（简单在回调解决），如果有人感兴趣的话，能够独自讲讲这一部分的解决，这里就先不做开展了。

第 35 ~ 40 行 —— 解决申请 data

config.data = transformData.call(
  config,
  config.data,
  config.headers,
  config.transformRequest
);

这里用到了一个 transformData 办法，次要的作用是合并 data，并且能够应用配置的 transformRequest 办法进行合并（如下图）。

而 transformData 办法就是遍历传入的 transformRequest 办法，将 data 和 headers 作为 transformRequest 的入参，而后将返回后果复制给 config.data，作为最初申请要发送的 data 内容。

第 43 ~ 54 行 —— 合并申请 headers

config.headers = utils.merge(config.headers.common || {},
  config.headers[config.method] || {},
  config.headers
);

utils.forEach(['delete', 'get', 'head', 'post', 'put', 'patch', 'common'],
  function cleanHeaderConfig(method) {delete config.headers[method];
  }
);

下面的代码次要做了两件事件：

  • 第一件事件就是将通用的 headers（common headers）和对应办法的 headers 以及原 headers 做了一个合并；
  • 第二件事件就是在合并实现后，将多余的 headers 配置删除。

第 56 ~ 58 行 —— 发动实在申请 

var adapter = config.adapter || defaults.adapter;

return adapter(config).then(function onAdapterResolution(response) {// ...});

这里应用了配置的 adapter，这其实就是发动申请的办法。

比方两个默认的申请办法，在浏览器端运行时应用的是 XMLHttpRequest，在 Node 端运行时应用的是 http 模块。

晓得这一项配置能够做什么呢？

你能够在这里传入一个自定义的申请办法，例如在客户端应用 fetch 封装，而不是 XMLHttpRequest。

你也能够在这里传入一个你封装好的 mock 办法，返回的都是本地 json 数据，用于 mock 数据，这样你就不必额定搭建一个 mock 服务啦。

……

言归正传，咱们还是来看看 axios 默认的两个 adapter 吧，本文会重点解说客户端 adapter —— xhrAdapter。

客户端 adapter —— xhrAdapter

咱们依照常规，对客户端 adapter —— xhrAdapter 逐行进行解析。

发动申请前的筹备工作

行数 形容
第 16 ~ 18 行 收集申请数据信息（requestData）、申请头信息（requestHeaders）、返回体类型（responseType）
第 19 ~ 28 行 对 cancelToken 做解决，在申请实现的时候勾销这个订阅，开释内存；还有对 signal 的解决，这个 signal 在文档中曾经看不到了，应该也是用于 abort 申请的。
第 30 ~ 32 行 对于 FormData 的申请移除 Content-Type 申请头，让浏览器主动设置申请头。

设置鉴权信息

首先在第 34 行，创立了一个 XMLHttpRequest 实例，用于后续的网络申请。

而后在第 37 ~ 41 行，设置了用于 HTTP basic authentication 鉴权的信息，从这一段咱们能够学到简略的 HTTP basic authentication 鉴权常识。

首先对 password 进行 encodeURLComponent 本义编码，而后再将用户名与明码依照规定拼接后，应用了 btoa 将 用户名与明码 转成了 base64 编码。

如果当前你要本人做这类事件的话，能够再翻到这一章节找到这部分的代码内容，抄一遍。

拼接申请 url

首先是用 buildFullPath 办法拼接了残缺的申请 url。（如下图）

能够看到，该办法对绝对路径的 url（isAbsoluteURL()）是不会拼接 baseURL 的。

而后，axios 还用 buildURL 办法将 params 参数拼接到了 url 中 —— 也就是咱们常说的 query 参数。（如下）

function buildURL(url, params, paramsSerializer) {
  /*eslint no-param-reassign:0*/
  if (!params) {return url;}

  var serializedParams;
  if (paramsSerializer) {serializedParams = paramsSerializer(params);
  } else if (utils.isURLSearchParams(params)) {serializedParams = params.toString();
  } else {
    // ...

    serializedParams = parts.join('&');
  }

  if (serializedParams) {
    // ...
    // 在这里，将解决后的参数作为 query 查问参数拼接到 url 中
    url += (url.indexOf('?') === -1 ? '?' : '&') + serializedParams;
  }

  return url;
};

这也是为什么应用 axios 时，GET 办法的参数要设置在 params 字段中。

而后，应用 request.open 办法初始化了一个申请。

响应回调函数

接下来就是比拟外围的响应回调函数了（如下图）

行数 形容
第 54 行 获取所有响应头
第 55 行 获取响应内容
第 57 ~ 64 行 设置 promise resolve 内容，就是你常常 console.log 进去的那些货色，你应该很眼生

设置其余回调函数

前面基本上都是设置 XMLHttpRequest 对象的一些回调函数了。（如下图）

比拟晚入行接触前端的，可能对 XMLHttpRequest 实例这些事件所做的事件不太分明，能够参考一下 XMLHttpRequest 文档。

最初，发送这个申请。（如下）

request.send(requestData);

回到 dispatchRequest

从下面能够看出，最初 dispatchRequest 调用 adapter 后，拿到了上面这些数据。

{
  data: responseData,
  status: request.status,
  statusText: request.statusText,
  headers: responseHeaders,
  config: config,
  request: request
};

而后咱们来看看 dispatchRequest 外部是如何解决这一段数据的吧。（如下图）

行数 形容
第 59/72 行 解决被 CancelToken 勾销的申请，如果申请已勾销则不持续向下执行
第 62~67 行 将响应后果通过 transformResponse 进行转换，失去解决后的响应数据
第 69 行 将响应后果返回

这样一来，整个 axios 的申请流程就梳理清晰了，咱们画一张流程图来梳理一下。（如下图）

这里对 Node 端的 adapter 就不进行开展解说了，和客户端的差别次要在于上面几点：

  1. 应用了 Node 的 http 模块发动申请。
  2. 能够通过 proxy 设置代理服务器，申请将会发送到代理服务器。

小结

好了，咱们对 axios 源码的解读就到这里为止了。

能够看出，axios 尽管是目前最风行的、比拟弱小的网络申请框架，然而源码看起来还是比拟清新易读的，倡议大家能够本人依照文章的思路去看看。

下一章，咱们会实现一个繁难的 axios 框架，蕴含 axios 的一些外围性能，将 axios 源码解读系列收官。

最初一件事

如果您曾经看到这里了，心愿您还是点个赞再走吧~

您的点赞是对作者的最大激励，也能够让更多人看到本篇文章！

如果感觉本文对您有帮忙，请帮忙在 github 上点亮 star 激励一下吧！

退出移动版