[Dart] [Client] Miscellaneous bug fixes for syntax errors, runtime exceptions, and deserialization errors
This update addresses a number of pain points I've encountered while using the Dart2 generator. I understand that this generator is considered deprecated, but as there has been no serious movement on the dart-next generator for 6+ months, I thought that it may as well get some attention.
This PR contains fixes for the following: #15393 (f80b51c5c56055d9eba86d01d0b24cbcb6ba0eec) #12456 (6e5368c58ecf504fde8ba8a67737d378b963d0b7 and 271bd9b1fafd59ee045c9ec17bede393d0e2306f) #17546 (8ed191c104ec09b413ae3252cceff03a71020628) #17547 and #13459 (83f5ecb2b44f0fd87acd44a6a483699c461e3e92) #12161 (1a30296185ecd9bef2def1a37772467149ce713d)
In summary:
-
File and Binary response return types are now marked as Uint8List instead of MultipartFile, which was never semantically correct
-
_decodeBodyBytes has been reworked to return either 'String' or 'Uint8List' based on the ContentType.
-
_deserialize now returns 'dynamic' to work with the new _decodeBodyBytes
-
Generated Enums now have equality and hashcode methods checking against their in-memory id then against their underlying value
-
Classes with a generated Numeric Enum in their constructor enums now instantiate sytactically correctly, without causing compile errors
-
Classes with default-available generated Enum in their fromJson() method now use a syntactically correct default, without causing compile errors
-
Added 'value' and 'apiClient' to reserved dart keywords, which is not strictly true, but allows for better generation of Enums that may use it
-
Added better double handling to 'mapValueOfType<T>', which previously would fail when deserding doubles
-
Moved from checking Response.body.isEmpty to Response.bodyBytes.isEmpty because .body implicitly converts to a utf-8 string which is will cause crashes when the data isnt utf-8
-
All local variables in the 'Api' generations now begin with an underscore to avoid name conficts with user supplied parameters
You can use the following OpenAPI file to test the generation: https://gist.github.com/0xNF/f0119f6a6a49424570803d7d3ed450ff
PR checklist
- [x] Read the contribution guidelines.
- [x] Pull Request title clearly describes the work in the pull request and Pull Request description provides details about how to validate the work. Missing information here may result in delayed response from the community.
- [x] Run the following to build the project and update samples
- [x] File the PR against the correct branch:
master - [x] If your PR is targeting a particular programming language, @mention the technical committee members, so they are more likely to review the pull request.
@jaumard (2018/09) @josh-burton (2019/12) @amondnet (2019/12) @sbu-WBT (2020/12) @kuhnroyal (2020/12) @agilob (2020/12) @ahmednfwela (2021/08)
If I can find the time, I'll try to break this out into n-many pull requests. It's quite a lot of overhead though, since there are really quite a lot of issues I am attempting to fix.
Adding on this topic, I have found that override is also missing from reserved keywords, and in an example I have seen there is a parameter in the openapi spec named override. This will generate a field in the model override and then the @override annotation on == and hashCode will throw compiler error "Annotation must be either a const variable reference or const constructor invocation.".
I understand that override is not a keyword in dart per se, but since it being a const var in the SDK used for obvious reasons, maybe adding that to the reserved keywords list would be a good idea?
This PR has been split into most of its constituent pieces:
- #17816
- #17811
- #17810
- #17809
- #17808
I have two PRs that I haven't pushed yet, including an implementation of OneOf and AnyOf, and one to fix name collisions. After those, I have some other improvements to the generator I'd like to make as well, but first I'd like to get these any issues sorted out, and these merged in.