-
-
Notifications
You must be signed in to change notification settings - Fork 6.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[DART] Add null-safety for dart 2.12+ #8278
Comments
I have thought about this for a while. We first need to ensure OAS3 nullable/required work correctly and then we can add a switch for this. Otherwise all properties would just be nullable which doesn't help much. |
Besides that, there is no nullsafety version from either |
This is not always correct. In OAS3 a field can be required but nullable. Required meaning it has to be serialized but may be serialized as |
Thanks @kuhnroyal . TIL. |
Yes, it is a pain to adopt null-safety at the moment as most of the packages are not null-safe yet. I am hoping that we'll have null-safe versions of major packages by March/April timeframe. Maybe then, it would make sense to prioritize this |
Thinking about possible and allowed API combinations: class Test {
String? text; // optional and non-nullable
String textWithDefault; // optional and non-nullable with default value
String? textNullable; // optional but nullable
String? textNullableWithDefault; // optional but nullable with default value
String textRequired; // required and non-nullable
String? textRequiredNullable; // required but nullable
Test({
this.text,
this.textWithDefault = "foo",
this.textNullable,
this.textNullableWithDefault = "foo",
required this.textRequired,
this.textRequiredNullable,
});
} To achieve this, we need to first make sure that it works without NNBD. |
#8235 contains some work on required/nullable |
Thanks @kuhnroyal. I have also started some work to get the dio package to support null-safety but it would likely take a few iterations to stabilize. 🤞🏽 |
@harsimranmaan I have created a PR which should generate the correct required/nullable fields as a precondition. Once this is merge I can start looking into getting your dio branch in here. |
Thanks @kuhnroyal . looking forward to it. |
I have now spent some time on this. I now think that we need to support the current templates for a while in the future but we also can't reliable get the new optional types into the existing templates as this does not only related to some model fields. I propose we copy the dart/dart-dio template folders and add a generator flag that switches the template folder path. |
TBH I don't really care about NNBD in Dart generators right now. There's plenty of other issues that need to be solved first. NNBD is cool, but having stable and battle-tested code base is more important imo. Having stable code that we know is safe, is more important than introducing drastic changes and testing them again. Dart 2.12+ isn't as close as it seems really, 2 days ago you had a dependency hell issues with test and http packages, updating min. dart version to 2.12 will make it much worse. It'll take time before wider adoption is there, so I also see no rush to get it working.
Yea, all for it, but it should live in new .mustache files as a new generator rather than a configuration flag to existing generator. Adding checks to put I'm leaving this fully with you @kuhnroyal and @harsimranmaan , I don't see urgent need to get it in 5.x |
Soo, we now have a beta version for Dio and it is not compatible with the current code. So we can not update the dependency ever unless we make breaking changes. And I think there will be more people looking for this soon once they notice they can't upgrade to the next Flutter version. The primary goal now is not NNBD but a version that is compatible with all the new dependency versions, and once we are there, then null-safety is not much to do. I have it already laying around. |
Ok, I discussed this with @wing328. I will add a new dart-dio-experimental generator that supports null-safety and will replace the current dart-dio generator when 6.0.0 is released. |
#8869 is up for testing |
Hi everybody, |
I don't think anyone is actively working on this for the dart-http client. |
I did most of the work on dart native client and json_serializable, 2.12 is still not on my roadmap anytime soon, but I can help you if you want to work on it. 60% of work will probably require copying what @kuhnroyal did in dart-dio. |
Hi everyone. When can we look at null safety? |
Any updates so far? @kuhnroyal : There was an update on the time_machine repository on 20th of july. Does that help you? |
This is still dependent on Dana-Ferguson/time_machine#55. |
I don't think anyone is actively working on the |
If no one else contributes this fix, I'll do it sometime in September |
@agilob Have you made any progress on this? |
yup, will open PR very soon |
does it make sense to model
|
@wing328 I think we can close this now |
Hey @kuhnroyal @agilob But has it been completed? Is there a way to generate dart code with |
Oh, great job; I look forward to the 6.0 release then. |
Is your feature request related to a problem? Please describe.
Starting with DART 2.12 dart packages support sound null-safety making it easy to detect common pitfalls during static analysis.
The current implementation of DART2 does not follow null-safety principles.
Describe the solution you'd like
The generated code should follow sound null-safety as per https://dart.dev/null-safety.
If an openapi field is not marked as required, it should be nullable by default: eg:
should generate a class
Customer
with fields likeString? id, String tenantId, String name, Datetime? createdAt
...Describe alternatives you've considered
Use the legacy mode until null-safety is supported.
Additional context
Required by gibahjoe/openapi-generator-dart#26
The text was updated successfully, but these errors were encountered: