search

cyclosproject / ng-openapi-gen

An OpenAPI 3.0 codegen for Angular
MIT License
397 stars 132 forks source link

Is mapping different naming conventions for properties of models in scope of this project? #158

Closed ggabriel96 closed 3 years ago

ggabriel96 commented 3 years ago

Hello there!

I'm currently using the OpenAPI Generator, but I have a problem when generating a TypeScript client for a Python backend. The thing is that snake_case is used in Python, while camelCase is used in TypeScript, and their Angular generator does not handle automatically converting these attributes (some do, but not the specific for Angular).

So I found this library and am considering using it, but I noticed that the generated models also keep the original name of the attributes. And in the read-me of this project there is a list of limitations with the following item:

No data transformation is ever performed before sending / after returning data. This means that a property of type string and format date-time will always be generated as string, not Date. Otherwise every API call would need to have a processing that would traverse the returned object graph before sending the request to replace all date properties by Date. The same applies to sent requests. Such operations are out of scope for ng-openapi-gen;

Does this mean that this feature will not be supported? It only mentions types, not names, and I didn't find any mention of such a feature, so I'm not sure.

Just to be clear, the feature would require generating the models with camelCase instead of the original naming convention and then adding some mapping from the original names to the new names. That mapping would be used right before a request is sent to the backend and right before returning the backend response to the caller.

By the way, very nice and clean code generation :)

luisfpg commented 3 years ago

Thank you.

You are right. The same limitation that prevents this lib from transforming value also applies to transforming fields. This library works with plain objects that are received / sent. There are no wrapper getters / setters that could use a different name for reading / writing using a different naming.

Think about how would you do it by hand in an Angular application to consume an API with snake_case fields while internally working with camelCase fields. The only way would be to wrap every possible object in the request / response graph to a class. And that's too much work for non-trivial models.

So, sorry, this wouldn't ever be supported.

ggabriel96 commented 3 years ago

Alright. Thanks for the quick response! :)