umi-request 无法将4xx结果作为一个正常响应

[tangye1234]

What happens?

需求是：服务器 status code 不管是什么，只要我们每次都拿到完整的 response 对象，就希望按照同样的正常结果处理，目前根据定义，可以通过 umi-request 的 options.getResponse = true 来获取到 data 和 完整的 response 对象。

但是意外的是，如果http status code 为400的话，居然抛了异常，并不会走正常的结果处理。这个和需求矛盾。

那就使用自定义的错误处理吧，umi-request 里 ts 声明 options.errorHandler 是不关心回调结果的 (error: ResponseError) => void，但实际的情况是，回调结果直接影响了 umi-request 的结果。

但更麻烦的情况是，假如我选择在 errorHandler 中将4xx 错误恢复成正常的 data 时，即使 getResponse = true，这个时候 umi-request 的 runtime 处理结果也不遵循 getResponse 的参数，而是遵循errorHandler 的处理结果，这个和 ts 定义的 Promise<RequestResponse<T>> 的返回类型也是矛盾的。

那好吧，如果选择自己来遵循，比如在统一错误处理回调 options.errorHandler 函数中判断是否含有 options.getResponse 时，却无法获取 options 参数，也就意味着，自己根本无法做统一处理。

至此，这类需求完全无法被统一处理。归根结底，主要是 umi-request 自作主张的 将 200-299 以外的错误做了强制 ResponseError 处理，即便我想正常关心 3xx 的结果也无济于事。

开始寻找给 umi-request 提bug，发现只能提 pr，只好转到 umi 项目里面提。

这里把它当成一个缺陷，是因为，errorHandler 的结果既然对响应类型 T 有影响，那么 umi-request 的调用返回类型 T 也应该遵循 errorHandler 的响应结果，否则，errorHandler 应该被定义为 (error: Error) => T 类型，仅仅用于修正 data 数据，或者继续抛异常

当然，也是一个需求，因为，这种 umi-request 自作主张只把 2xx 当成正常结果处理，和 fetch 组件把这个机会留给开发者自己，扩展性损失了很多。

对于我来说，感觉从 antd-pro v1 => v2 => v4，breaking changes 时刻发生，部分地方 umi 化后，越来越限制使用姿势，甚至要做非常多的 workaround 来兼容。

[mankeheaven]

用umi-request也是遇到了不少问题，转axios了

[clock157]

将 4xx 当作错误来处理是我们的约定。如果你的项目不大一样，你可以通过拦截器来处理一下 response 即可。

request.interceptors.response.use((response, options) => {
  return new Response(response.body, {status: 200, statusText: 'ok', headers: response.headers
});

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[dmwin72015]

将 4xx 当作错误来处理是我们的约定。如果你的项目不大一样，你可以通过拦截器来处理一下 response 即可。

request.interceptors.response.use((response, options) => {
  return new Response(response.body, {status: 200, statusText: 'ok', headers: response.headers
});

这和约定没多大关系吧？？

[tangye1234]

@dmwin72015 完全没关系，如果不用和他们的约定不符时，根本没办法这么做，他的这种做法，修改statusCode 和 statusText，我感觉，才是奇怪。

[TORYOI]

laravel 接口用的Dingo，在验证输入、用户登录权限失败时，返回的是4xx码，通过拦截器来处理 response是可以了，但是感觉别扭。