umi-request & useRequest 源码分析及业务实践

导读

文章通过业务点分析以及深入umi-request,useResut的源码，来探索 umi-request 赋能小程序请求，以及 useRequest 赋能后台业务.

1. 业务梳理

1.1 常见问题

1.page目录、service目录、model目录、typescript目录，utils 目录，所有不同类型的业务逻辑都被拆分在不同的目录内，且还存在相互引用,以及嵌套层级很深，在开发一个页面的时候难以聚焦。
2.被频繁引用的模块中 if else 使用很多，且存在嵌套，如果需要加入新的逻辑，由于逻辑不清晰，在引入新功能时容易影响老的逻辑，由于被各个页面频繁引用，波及范围较大，容易出现线上问题。
3.在涉及到后台的定义接口以及使用的过程中，每增加一个接口，都会涉及到对应接口的 loading状态，data状态，error状态，请求前，请求后的处理，当一个业务点涉及的异步逻辑很多的时候，整个业务逻辑会变得很臃肿。

1.2 解决方案

1.每一个 page 的不同类型的业务逻辑都放在一个目录内
2.引入umi-request 来包装 uni-request
3.引入 useRequest hook，在定义接口文件的时候，同时预实例化对应 service 的hook，便于开发。
4.将具体页面的状态管理交给 hook，全局的状态交给 model。

2. 将 umi-request整合进小程序，告别 if else

基于uni-app 的 uni.request ,非 promise,只有 onSuccess，onFail 回调,小程序不支持urlSearchParams, 手动替换 coreMiddleware

2.1 小程序请求的一般逻辑流程图

以下代码均为伪代码，描述整体的脉络。

function request(url: string, options) {const { noErrToast = false, noLoginToken = false } = options;const params = cloneDeep(data);if (needLoginToken) {if (token) setToken();else return noLoginCallback();}// 删除无效入参removeNillParams(params);return new Promise(function (resolve, reject) {uni.request({url,...options,success(res) {printSucessResponse(res);if (res.code === ErrorCodeA) return specificCodeErrorCallback(res);if (res.code === ErrorCodeB) return specificCodeErrorCallback(res);if (res.code === ErrorCodeC) return specificCodeErrorCallback(res);if (res.code === LOGIN_EXPIRED)return specificCodeErrorCallback(res);if (options.simpleResponse) {if (res.code === SuccessCode) resolve(simplify(res));else {if (options.autoErrToast) return specificCodeErrorCallback(res);reject(res);}} else {resolve(res);}},fail(err) {printFailResponse(err);if (err.errMsg?.startsWith(ErrorMessageA))return specificCodeErrorCallback(err);if (err.errMsg.startsWith(ErrorMessageB))return specificCodeErrorCallback(err);return specificCodeErrorCallback(err);},complete(res) {console.log("request complete =>", url, res);},});});
} 

2.2 umi-request