-
-
Notifications
You must be signed in to change notification settings - Fork 31
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
Create a test and example using enums. #110
Comments
I also struggle to get back the behavior from version 0.5.3 which e.g. generated
instead of version 1.3.0 now generating
Using Edit: Here's an excerpt from the used API spec: "CreateRepository" : {
"required" : [ "type", "url" ],
"type" : "object",
"properties" : {
"type" : {
"type" : "string",
"enum" : [ "GIT", "GIT_REPO", "MERCURIAL", "SUBVERSION", "CVS" ]
},
"url" : {
"type" : "string"
}
}
}, |
Maybe this could be related to hey-api/openapi-ts#547? |
That does seem related. There are lots of moving parts. Maybe fallback to an old version of this library until the new release of @hey-api/openapi-ts |
The new version 0.44.0 of openapi-ts fixes this problem and generates enums again. |
The changed query client lead to some fixes needed in the UI code to adapt to changes, which are listed here for further reference: - to access the "message" and "cause" fields of the ApiError body in the error toast component, intermediate type casting of error.body to "any" was needed. NOTE: it should be investigated, why this has changed, as before we had direct access to error.body.message and error.body.cause in the UI - earlier on, the service functions like ProductsService.getProductById() were called with passing parameters directly, but now the parameters need to be passed as objects - The openapi-react-query-codegen uses openapi-ts as an underlying engine for code generation, and inline enums were broken in the latter [2]. While this has already been fixed in openapi-ts, the fix has not yet been taken into use in openapi-react-query-codegen [1]. Until the openapi-react-query-codegen is updated, the inline enums need to be accessed differently, as in z.nativeEnum(CreateRepository.type) needs to be changed into z.enum($CreateRepository.properties.type.enum) Note that when the library is updated, this change probably needs to be reverted back to its original form. [1]: 7nohe/openapi-react-query-codegen#110 [2]: hey-api/openapi-ts#547 Signed-off-by: Jyrki Keisala <jyrki.keisala@doubleopen.org>
The changed query client lead to some fixes needed in the UI code to adapt to changes, which are listed here for further reference: - to access the "message" and "cause" fields of the ApiError body in the error toast component, intermediate type casting of error.body to "any" was needed. NOTE: it should be investigated, why this has changed, as before we had direct access to error.body.message and error.body.cause in the UI - earlier on, the service functions like ProductsService.getProductById() were called with passing parameters directly, but now the parameters need to be passed as objects - The openapi-react-query-codegen uses openapi-ts as an underlying engine for code generation, and inline enums were broken in the latter [2]. While this has already been fixed in openapi-ts, the fix has not yet been taken into use in openapi-react-query-codegen [1]. Until the openapi-react-query-codegen is updated, the inline enums need to be accessed differently, as in z.nativeEnum(CreateRepository.type) needs to be changed into z.enum($CreateRepository.properties.type.enum) Note that when the library is updated, this change probably needs to be reverted back to its original form. [1]: 7nohe/openapi-react-query-codegen#110 [2]: hey-api/openapi-ts#547 Signed-off-by: Jyrki Keisala <jyrki.keisala@doubleopen.org>
Is your feature request related to a problem? Please describe.
There are consumers of this library that use enums, we have no tests or examples showing their generation/usage.
Describe the solution you'd like
A unit test or snapshot showing their creation.
Describe alternatives you've considered
None,
The text was updated successfully, but these errors were encountered: