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
core improvements: type predicates, keep AxiosResponse & display human errors #12
Conversation
I recently discovered functions whose return types are a _type predicate_. It's really useful to transform types (narrowing down types) when you check the type is compatible with what you expect. It adds a bit of clarity in the code by moving the type guards in dedicated functions. (more details of type predicates: https://www.typescriptlang.org/docs/handbook/2/narrowing.html#using-type-predicates) _Note: the commit also makes use of a second discovered TS feature, the Type intersection (`&`) to “extend” existing types with more attributes and make them compatible for narrowing. ✨_
The current response interceptor was keeping only the response body of every http API calls. However it's not what we want. We want to be able to check response bodies but also response status for instance. In this commit such need is not very visible (because we don't read any response status) but for later changes it will be good, especially for error handling. The good thing about this change is that it removes the `any` type I had to use to “trick” axios.☺️
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I left a lot of comments, part of them are due to my unknowledge of Typescript, sorry for those. It seems to be really good moves, congrats on this refactoring!
This is changing the way we display known invalid definition server errors. It's good to make the presentation of known possible errors more presentable to humans.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I left a final comment on naming, but I think that it's out of the scope of this PR. But, if you agree with me, maybe it would make sense to change it in the upcoming days?
Besides this point, LGTM.
This PR is a refactor that contains three improvements. Please see details for each in their commit description: