Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[RFC] 更改默认适配器的行为 #49

Open
ModyQyW opened this issue Jun 6, 2024 · 1 comment
Open

[RFC] 更改默认适配器的行为 #49

ModyQyW opened this issue Jun 6, 2024 · 1 comment
Labels

Comments

@ModyQyW
Copy link
Member

ModyQyW commented Jun 6, 2024

背景

目前,默认适配器会在 uni.request/uni.uploadFile/uni.downloadFile 的 fail 回调中设置 response 而不是调用 reject 抛出 UnError,可见:

因此,在后续操作进入 settle 方法后,由于不存在 status,所以会被 resolve,可见:

最后导致用户可能需要在 response 中处理 error。

一个更详细的例子如下,可以通过修改 playground 得到相同的结果:

// 设置很短的超时时间
un.get('https://jsonplaceholder.typicode.com/todos', { timeout: 10 })
  .then((data) => {
    console.log('data', data);
  })
  .catch((error) => {
    console.log('error', error);
  });

在 axios v1.7.2 xhr 和 fetch 两个 adapter 中,超时将得到 AxiosError 相关的输出。

https://github.com/axios/axios/blob/v1.x/lib/adapters/xhr.js#L110

https://github.com/axios/axios/blob/v1.x/lib/adapters/fetch.js#L217-L225

但在这里将得到 data 相关的输出:data {errMsg: "request:fail timeout", errno: undefined},这极有可能会造成用户侧的困扰:为什么不是 error 呢?

提议

修改三个默认适配器,在 fail 回调中调用 reject 抛出 UnError,使得相关行为与 axios 保持一致。该修改属于破坏性修复,考虑纳入 v0.19 或 v1。

额外上下文

最初想法源于 https://github.com/Lin-w-b ,非常感谢与我的沟通。

@peerless-hero
Copy link

peerless-hero commented Dec 1, 2024

参考:https://github.com/axios/axios/blob/v1.x/lib/adapters/xhr.js
axios请求库在xhr触发onerror 事件时,直接触发reject 相关的部分,而不是settle相关的部分。
onerror 事件一般会在完全无法获得服务器响应时触发,此时将会触发axios的全局响应拦截的错误回调。

目前uni-network适配器在遭遇上述情况时,只会进入全局响应拦截,严重影响判断。
我经过测试,发现只要是服务器有响应的请求,uni.request、uni.uploadFile等方法只会触发success方法,能进入fail的情况只有断网、服务器证书配置错误、host解析失败等情况,个人认为这些情况下应该进入全局的响应拦截器的错误回调而非成功回调。

这种情况让我排查请求BUG时遇到了很大困扰,所以我对此提了一个PR。

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants