umi-request 中间件和拦截器解析

前言

使用react框架中经常使用到umi来搭建管理我们的项目，其中涉及到请求的模块，umi自身提供了 umi-request 库 方便了我们做网络请求， umi-request的官方文档可见其githubREADME.MD文件, 大部分功能都在readme中查询，大部分功能已经将的很清楚了，单独拿出 middleware和 interceptors 这两个概念讲一下。

为什么是 middleware和 interceptors

在使用umi-request的过程中最常见的需求是，对网络请求的拦截，在请求前或请求后做一些事情，例如URL添加前缀，过滤无效参数，上报接口错误，页面错误统一处理，单独接口定制化处理等...， middleware （中间件） 和 interceptors (拦截器) 以及 errorHandler 是实现此类需求绕不过去的概念，虽然他们都能影响请求和返回结果，但是哪种场景下使用哪个函数？需要了解其实如何实现的，以及代码的前后执行逻辑。

核心代码

  // onion/index.js
  execute(params = null) {
    const fn = compose([
      ...this.middlewares,
      ...this.defaultMiddlewares,
      ...Onion.globalMiddlewares,
      ...Onion.coreMiddlewares,
    ]);
    return fn(params);
  }
 

1. middlewares 和 interceptors.response 的关系 伪代码就是 middleware(ctx) ctx 对象中包含responseInterceptors函数 ，也就是说responseInterceptors函数 会作为 middleware的参数使用
2. compose函数会把middlewares中的函数按照顺序串联成一个可以递归调用的函数，fn(params) 会把这个递归调用函数执行掉

关于middleware

• 使用

  • request.use(fn) // 默认加载到 onion实例上
  • request.use(fn, { defaultInstance: true })
  • request.use(fn, { global: true })
  • request.use(fn, { core: true })

• 调用逻辑：extend(configObj)生成request实例，request初始化中生成一个Core实例，Core实例初始化中使用一个Onion实例， 我们调用的request.use实际上是Onion实例上的use方法

• use方法的第二个参数是可选参数，根据这个配置决定这个middleware加载到哪一层，调用的顺序也是不一样的，具体查看官方给的示例，

• request.use(fn) 默认加载到 onion实例上，执行的时候会首先进入这一类的middleware

• request.use(fn, { defaultInstance: true }) 官方给出的描述是 “默认实例中间件，供开发者使用”，此类middleware还是会加载到Onion实例上，默认Core实例中给出了"[]"的配置

• request.use(fn, { global: true }) ，全局中间件中本身就内置了三个函数 [simplePost, simpleGet, parseResponseMiddleware]

  • simplePost实现了默认请求头设置， ‘Content-Type‘: ‘application/json;charset=UTF-8‘ 自动配置form类型的请求头； 功能在next()前；
  • simpleGet实现了get请求使用params参数自动序列化；功能在next()前；
  • parseResponseMiddleware实现了Http Status Code 的判断 copy.status >= 200 && copy.status < 300 之外的code会作为错误被抛出; 功能在next()之后；
  • 自己加入的middleware会放在这三个后，执行的顺序用洋葱模型理解一下就是“后进先出”

• request.use(fn, { core: true })， 核心中间件内置了一个函数 [fetchMiddleware], 也是umi-request真正发起接口调用的地方，使用的是浏览器原生的fetch对象

• fetchMiddleware 实现了浏览器兼容性判断，缓存数据获取，超时逻辑，取消请求功能；在原生fetch请求回的第一时间，就进入了responseInterceptors的函数，所以interceptors.response.use进来的拦截器函数是第一批接触到真正fetch返回的response对象的函数，此时的response 对象是没有经过包装的原生fetch请求回来的对象，对象上常用的属性有status, statusText, ok等属性

关于Interceptors 拦截器

• Interceptor分为两部分，请求前的拦截，请求后的拦截
• 请求前的拦截，是在进入洋葱模型之前执行的函数，也就是说interceptors.request.use中的函数，会比任何middleware中的函数执行的早

   return new Promise((resolve, reject) => {
      this.dealRequestInterceptors(obj) // 在此处完成了interceptors.request.use中函数的执行
        .then(() => onion.execute(obj))
        .then(() => {
          resolve(obj.res);
        })
        .catch(error => {
        ...
    });

• 请求前的拦截可以操作的属性或对象只有 url 和 options 两个，只对这样个对象进行操作
• 请求后的拦截是在 onion洋葱模型的 最深处 执行，也就是上面提到的fetchMiddleware在获取到fetch response 对象的第一时间会交给interceptors.response.use中的拦截函数处理

errorHandler

• errorHandler执行的时机最晚，在各种拦截器各种中间件执行完成以后,这个时候如果捕获到了异常才执行。
• 默认的errorHandler的逻辑是，如果有配置errorHandler，errorHandler垫底，如果没有配置errorhandle会直接抛出异常；
• 单个请求option的 errorHandler 会覆盖 extend(config) 中的 config.errorHandler， 这属于option覆盖的逻辑，不展开细讲，有不懂的可以看一下官方文档或源码

middleware 和 interceptor 可以拿到的参数

• 先看下ctx 对象

 const obj = {
      req: { url, options },
      res: null,
      cache: this.mapCache,
      responseInterceptors: [...Core.responseInterceptors, ...this.instanceResponseInterceptors],
    };

• middleware(ctx, next) 函数 next 表示进入到下一层（里面一层），next 前的逻辑和next后的逻辑，按照洋葱的进出的定义来理解，ctx 就是上述ctx对象
• requestIntercetor的参数是 url 和options配置
• responseIntercetor的参数是 原生的fetch产生的res对象

最后结合官方的示例理解一下执行顺序

request.use(async (ctx, next) => {
  console.log(‘instanceA1‘);
  await next();
  console.log(‘instanceA2‘);
});
request.use(async (ctx, next) => {
  console.log(‘instanceB1‘);
  await next();
  console.log(‘instanceB2‘);
});
request.use(
  async (ctx, next) => {
    console.log(‘globalA1‘);
    await next();
    console.log(‘globalA2‘);
  },
  { global: true }
);
request.use(
  async (ctx, next) => {
    console.log(‘coreA1‘);
    await next();
    console.log(‘coreA2‘);
  },
  { core: true }
);

// 执行顺序是
instanceA1 -> instanceB1 -> globalA1 -> coreA1 -> coreA2 -> globalA2 -> instanceB2 -> instanceA2

再加上我们上面的理解可以理解成这样

// 看一下fetch的位置
instanceA1 -> instanceB1 -> globalA1 -> coreA1 -> fetch() -> coreA2 -> globalA2 -> instanceB2 -> instanceA2

// 看一下内置中间件 + 拦截器的执行顺序 
requestInterceptor -> 自定义middleware -> simplePost-> simpleGet-> parseResponseMiddleware -> fetch -> responseInterceptor 
自定义middleware <- simplePost <- simpleGet <- parseResponseMiddleware  <-

写在最后

虽然没有具体规定哪个函数应该做什么，但是知道执行顺序以后，就很方便我们拓展了

umi-request 中间件和拦截器解析

原文：https://www.cnblogs.com/wuhaozhou/p/14030540.html