-
Notifications
You must be signed in to change notification settings - Fork 247
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
networkError method should define a request attribute in mocked error response #168
Comments
+1 |
1 similar comment
+1 |
@tiagobnobrega how did you manage to workaround this? replying with [0, 'Network Error'] returns an error with both actually it puts |
@dreyks What I do is normalize error object to always have a statusCode attribute as a root property. it first tries to take the status from the response, then checks for request and finally defaults to some code. This way, even if it has a response with a status of "0" (zero). That code will be defined. I currently have this (in typescript): interface RequestError extends AxiosError {
status: number;
data?: object;
}
function normalizeRequestError(error: AxiosError): RequestError {
const {response, request} = error;
if (response) {
/*
* The request was made and the server responded with a
* status code that falls out of the range of 2xx
*/
const {data, status: responseStatus} = response;
return {
...error,
status: responseStatus, // <- This would be zero in the mock returning [0, 'Network Error']
data,
};
} else if (request) {
/*
* The request was made but no response was received, `error.request`
* is an instance of XMLHttpRequest in the browser and an instance
* of http.ClientRequest in Node.js
*/
return {
...error,
status: 0, //<- also set to zero in actual code
};
} else {
//* Something happened in setting up the request and triggered an Error
return {
...error,
status: -1,
};
}
} |
Would like to know if there is any progress on this? |
When calling networkError, the error returned by the lib should define a request attribute. This is how axios works. It's important because error handling rely on the error.response check. Such as:
I've managed to workaround this by replying [0,'Network Error']. But, I guess it's not the ideal solution.
The text was updated successfully, but these errors were encountered: