Support for String/Num Enum values

[agilob]

Enum needs to be annotated what value we see in code and what name of the value is in JSON. eg

• enum Color {Red, Blue} I need to be able to use Color.Red in Dart, but serialise Red to red In real life example, (zyx) or _abc are valid enum values that can be present in JSON
• Smiliarly for numeric enums 1.1 and -2 are valid values
  Value in code is something we generated in openapi, eg. in spec you see -1.1 we should generate minusOneDotOne or something similar, but we need a way to tell JSON serialiser to turn minusOneDotOne into -1.1 in JSON and it has to be -1.1 double value not string value "-1.1"

[agilob]

This must also be compatible with defaultValue

[kuhnroyal]

That is probably not possible with pure enums.

[agilob]

It's supported with json_serializable, which generates map of key-value and simply queries the map for dynamic type of JSON value and converts that dynamic obj to enum field value. It's almost identical how we do it with transformer classes

Edit: Actually, I dont know how I did it in one project, cant reproduce it now... might be wrong here. Anyway we have it working that way in openapi-generator so it would be nice to 1. convert the enum to proper enum class 2. have it working with numeric/string enums. so the converter map will probably stay with us for a while

[agilob]

This issue is also the lowest priority of the 3, it's more like "nice to have" than a blocker.

[k-paxian]

It has to be properly designed first. It could take some time to nail it down nicely.

• It needs to respect defaultValue here
• It needs to respect CaseStyle here
• It needs to respect simultaneously customization via custom converter here and play nicely with the default global converter.
• It requires to be supported from the builder side with additional annotation (like @JsonValue from json_serializable)

inspired by google/json_serializable.dart#778

It's really ambitious, I like it 👍

[agilob]

It needs to respect CaseStyle here

I agree but that's one caveat, different openapi generators have different options for naming conventions, there is no strict standard about it. All styling and naming conventions are just up to what developers of a generator produce. There are some generators that allow users to produce differently formatted code. This schema is pain in the ass for many generators because of the enums. It's really full of edge cases, pain-points, full of unrealistic type structures, types and names.

In the end it's up to us openapi-generator developers what naming convention we use, and it's always, 100%, camelCase, but we also shouldn't restrict anyone from adding another generator with kebab-case or HaNAnMONtanACas-E if they wish so.

It requires to be supported from the builder side with additional annotation (like @JsonValue from json_serializable)

Yes, that's actually the good thing in json_serializable, but also the bad thing (only used enums have generated builders. Standalone enums that aren't used in any classes do not get the marshaller/unmarshaller code generated. If it only had an annotation for @JsonEnum it would be ready for our openapi-generator.

It needs to respect defaultValue here

The check the schema above, it has enum field with default value line 607

[agilob]

And again, it's a nice-to-have than a must-have. Your library is solving the blocker we had in json_serializer, so it's already better suited I think.

I'm going to try your library in my project over the weekend and try to prepare a PR in openapi-generators if I have enough time. I need to see how it works with maps, list of maps, maps of lists etc. Yes, schema has such fields.

[k-paxian]

Shipped: https://github.com/k-paxian/dart-json-mapper#enums-having-string--num-values

[agilob]

Have to say, impressive.