Skip to content
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

[typescript-fetch] (4.0.X) Feature Request: Use OperationID to name Inline Responses #1626

Open
someone1 opened this issue Dec 6, 2018 · 3 comments

Comments

@someone1
Copy link
Contributor

someone1 commented Dec 6, 2018

Description

Personal choice but I don't think the naming of inline models is very useful:

image

openapi-generator version

openapi-generator-cli-4.0.0-20181206.114535-69.

OpenAPI declaration file content or url

See #1563 for an example

Command line used for generation

openapi-generator generate -i openapi.yaml -l typescript-fetch -c es6.json -o ./typescript-api/

Steps to reproduce

See #1563 for an example

Related issues/PRs

N/A

Suggest a fix/enhancement

Is there any opposition to renaming these based on the OperationID? Each is required to be unique and is probably a more descriptive name to use. I think there's the option to add a title attribute to each, so maybe it can go title -> operationID_xxx vs the static inline_response_xxx fallback?

This change would be far-reaching, and I've only really seen the output for the typescript-fetch client, I'm not sure how its handled in other generators.

@wing328
Copy link
Member

wing328 commented Dec 6, 2018

To have complete control of the model naming, I would suggest defining the model properly (example) and use $ref to reference it throughout the spec.

@someone1
Copy link
Contributor Author

someone1 commented Dec 6, 2018

I guess for my use-case it's somewhat repetitive, most of my inline responses are paginated and are an allOf composition of a pagination model and an array of the model for that API (e.g. User).

I realize this is personal preference but the current naming could (arguably) be made better without the user having to add more models to the spec.

If this isn't a direction to take the project in or is too big a breaking change, feel free to close! I knew opening it that it was more personal design choice.

@joho
Copy link

joho commented May 3, 2019

I'd also really appreciate this change.

I codegenerate my swagger.json from my integration tests using https://github.com/domaindrivendev/rswag

The problem this is causing me is when I add new endpoints they're often inserted in the middle of the swagger json, and so some of the generated models are shuffled down, and if I have a named import to one of the inline responses I have to manually go back and change my client code.

It'd be really helpful if the response object names were deterministic based on the operation name rather than based on the order in the config.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants