Autogenerated variables can be improved

[gabn88]

Describe the bug
The autogenerated variables are incorrect

Now the enums are fixed (#1113), we would like to use the Enums to generate the variables for the choices automatically.

For example:

class IntensityChoices(IntegerChoices):
   LOW = 1, 'low'
   HIGH = 2, 'high'

Becomes

    IntensityEnum:
      enum:
      - 1
      - 2
      type: integer
      description: |-
        * `1` - low.      
        * `2` - high.

Becomes (typescript generator):

/**
 * * `1` - low
 * * `2` - high
 */
export enum IntensityEnum {
  '_1' = 1,     // We would like to see; LOW = 1
  '_2' = 2,   // We would like to see: HIGH = 2
}

Expected behavior
Keep varnames from the server Enum and use them for the varname in the Enum in the schema

[tfranzel]

hey @gabn88, that didn't take long. 😄 we had this discussion in other issues also.

So this is now a external limitation basically and it has been raised several times. OpenAPI 3.0.3 has no way to give an enum list a programmatic label list. The description is merely a string and just writing low or high there will change nothing from the perspective of the generator. We just implemented the recommendation: https://swagger.io/docs/specification/data-models/enums/

OpenAPI 3.1 does have a construction that allows this. After years of back and forth this was recently decided: OAI/OpenAPI-Specification#681

However, 3.1 integration in #825 is not merged yet and on top of that, the new construction is not implemented yet.

[gabn88]

@tfranzel You are also fast, thank you for the update on #1113!

I modified the issue a bit, as I think there are actually two issues.

1. is for the label (requires 3.1, "other issue / non-fixable for now")
2. is for the var names. Our frontend team is not very happy with the readability of Activity._1 (where _1 means LOW).

I thought the second issue is maybe fixable?

[tfranzel]

I get the pain on point 2. I had that pain myself, but OpenApi 3.0.3 has no official structure for it and the community/ecosystem was never able to settle on a solution. So all hacks only have limited support and adding a bunch of different hacks here will only lead to (maintainer-)misery. This is as good as it gets for 3.0.3 and it is basically completely out of our/my control.

We can implement that new convention OAI/OpenAPI-Specification#681 (comment) after merging 3.1 support, but it looks like the ecosystem has no support for this yet either.

[gabn88]

I see your point. Let's hope we get there some day. Thanks for your patience with answering my questions!