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

前言

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

为什么是 middlewareinterceptors

在使用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  <-

写在最后

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

(0)

相关推荐