-
-
Notifications
You must be signed in to change notification settings - Fork 4.2k
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
feat: console error messages and better names for requests imported from openapi #3948
base: main
Are you sure you want to change the base?
feat: console error messages and better names for requests imported from openapi #3948
Conversation
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.
The changes work as expected. However, there are cases where the url can contain variables (eg. /pet/{petID}
, in this case, the name given will be <<petID>>
if there are no operationID
or summary
properties). I am not sure that's a good approach to the naming scheme in this case. @amk-dev Can I get your thoughts on this?
let defaultRequestName = "Untitled Request" | ||
|
||
if (info.tags?.length) { | ||
const pathStartIndex = |
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.
here this logic will miss some edge cases,
i belive you're assuming that the tag will always be present in the path, but that won't always be the case.
- what happens if the tag is no way related to the path ?
- adding the tag length makes sense only if the tag is found in the path, otherwise you're adding the length to -1, which does not makes much sense.
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.
No. If it does not have a tag then the condition is not met and is saved as a request without a title. What I can do is save it with the name of the controller in the request in case it don't have tags.
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 quoted the wrong lines actually. the comment is meant for the next line.
const pathStartIndex =
openAPIPath.indexOf(info.tags[0]) + info.tags[0].length
and i didn't mean when the tag is not present, i meant when a tag is present but it is not in the url.
like this,
/categories/{categoryId}/items:
get:
tags:
- SomethingNonRelatedToTheURL
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've been thinking about it, and I can't find a way to know from which text index to parse the url as name, any idea? My initial motivation for using the tags was because normally people generate the openapi specs automatically based on the code in their apis, but with the point that the first tag may not be the controller itself, I can't think of another idea.
openAPIPath.indexOf(info.tags[0]) + info.tags[0].length | ||
|
||
if (pathStartIndex > 0) { | ||
defaultRequestName = |
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.
when naming the request, here it seems we're considering the first value after the tag only, eg: the current logic will name /categories/<<categoryID>/update
as <<categoryID>>
, but i would prefer the request to be named, whatever the remaining path is after the tag. in this case <<categoryID>>/update
Closes #
Description
This PR shows an error message in console when an error occurs when parsing the OpenAPi file, since actually there is no error message, just a generic message, and it is impossible to know why the import failed (I spent 30 minutes looking for what was wrong with my file lol).
Also, in the requests, we currently try to obtain the name with the following steps:
Currently, most of the request names always arrive in this 3rd step because usually the schemas that I have found do not define the summary property or things like that, so in this PR we try to extract the name from the URL of the request, so that the name is more understandable and not have folder with requests named as untitled request. Attached is evidence of how it was before and how it is now.
Checks
Additional Information