Swagger-codegen: [Angular2] attributes are snake_cased

[creat-or]

Description

In my generated files, the attribute in the model interfaces are all camelCased, but the fetched data is snake_cased and not changed.

export interface User {
    /**
     * The ID of the user.
     */
    userId: number;
[...]

returned object: { user_id: 12, ... }

Swagger-codegen version

the version used by http://editor.swagger.io/

Notes

However, when sending some formParams (POST) to the server, then the generated code converts the attributes:

if (challengeId !== undefined) {
    formParams.set('challenge_id', <any>challengeId);
}

[toshe]

Basically on a GET request the server returns { user_id: 12, ... } and it isn't assigned correctly to the model because the model now uses camel case, userId: number. There is no snake_case -> camelCase conversion taking place when getting resources.
When posting resources the camelCase gets correctly converted to snake_case.

[wing328]

Please try to generate the client from 2.3.0 branch as there's an enhancement to deserialize the JSON object properly: https://github.com/swagger-api/swagger-codegen/pull/4264

[zoltanszekely]

@wing328 I might be wrong but #4264 is a change to the typescript-node clients only.

[zoltanszekely]

Just to clarify, neither requests or responses perform any mapping between the JSON keys and interface attribute names which makes it impossible to use snake_cased keys in the API.

[glebmachine]

+1 got the same at latest version (2.2.2)
target: typescript-angular2

[wing328]

One way is to use the following option to keep the original naming:

    modelPropertyNaming
        Naming convention for the property: 'camelCase', 'PascalCase', 'snake_case' and 'original', which keeps the original name (Default: camelCase)

Ideally we want to port the same logic for deserializing JSON in typescript-node to other typescript generators (fetch, angular2, etc)

[dinvlad]

I assume it's not been ported yet (even on 2.3.0), for now we have to just specify --additional-properties modelPropertyNaming=original? Thanks

[grEvenX]

This is still the case on 2.3.0 branch and it caught my completely by surprise since it won't give you any errors until you inspect data sent/retrieved on the network requests.
I think it's pretty important as the results of this is not as expected.
The workaround to use --additional-properties modelPropertyNaming=original works fine.

I can't make any promises, but I may be able to work on porting #4264 to this generator during my vacation starting next week.

[grEvenX]

After looking more at the issues this seems to be a duplicate of #4857 which already has a PR?

[wing328]

Yup, please review https://github.com/swagger-api/swagger-codegen/pull/6024 to see if it works for you.

Here are the steps:

git checkout -b ard61-fix_issue4857 2.3.0
git pull https://github.com/ard61/swagger-codegen.git fix_issue4857

[netrounds-joakim]

No news on this?

I'm a bit perplexed why --additional-properties modelPropertyNaming=original isn't the default on all generators?

If one specifies in the schema that the data is named something_cool, and you then return that via the API. How could any sensible user of that API ever think it's ok to just assume it would be named somethingCool in the client?

A person looking at the API schema would not assume this, so why should a code generator do such a thing? Unless there is an explicit conversion included in the code.

To me it would make more sense to have the conversion be the option, not default. Especially since this causes things to fail silently until you run the code.