quicktype
quicktype copied to clipboard
glideapps
Add Dart non-nullable support
As Dart non-nullable is stable now, please add option to generate non-nullable classes with the tool (especially freezed classes)
It looks to me like that all that is needed for null safety is to make it work exactly like make all fields required, but to use just 'required' as the filed prefix, instead of '@required'. It should probably be under its own switch so that you keep the old functionality.
Also the tool should detect if some field may be nullable (eg. If some field has null value in provided json).
Think about copyWith(...). The dart migration tool treats the copyWith parameters as non-nullable. I had to manually put question marks to each of the parameters (sorry I'm bad at regex). All parameters in the copyWith method should be nullable to properly implement the prop: prop ?? this.prop expression.
It shouldn't even be an option. Quicktype must generate copyWith with all parameters as nullable. With ?
Imagine a copyWith method with all parameters as required (non-nullable). That would be a disaster.
This is what freezed null-safely generates:
class _$ShopCopyWithImpl<$Res> implements $ShopCopyWith<$Res> {
_$ShopCopyWithImpl(this._value, this._then);
final Shop _value;
// ignore: unused_field
final $Res Function(Shop) _then;
@override
$Res call({
Object? shopCode = freezed,
Object? shopName = freezed,
}) {
return _then(_value.copyWith(
shopCode: shopCode == freezed
? _value.shopCode
: shopCode // ignore: cast_nullable_to_non_nullable
as String,
shopName: shopName == freezed
? _value.shopName
: shopName // ignore: cast_nullable_to_non_nullable
as String,
));
}
}
dart code generation packages.. stopped using since 2019. especially with localizations. I just personally hate it. the explanation would be too long. It's based on experience. also, not all people use freezed or any code generation dart packages.
It looks to me like that all that is needed for null safety is to make it work exactly like make all fields required, but to use just 'required' as the filed prefix, instead of '@required'. It should probably be under its own switch so that you keep the old functionality.
Also, when the JSON fields are optional the generated class fields should be nullable with ? suffix, and references to the fields (after null check) should assert non-null using !, for example:
class Sensordata {
...
String? sensor;
List<Datum>? data;
...
Map<String, dynamic> toJson() => {
"sensor": sensor == null ? null : sensor,
"data": data == null
? null
: List<dynamic>.from(data!.map((x) => x.toJson())),
};
}
class Datum {
...
String? value;
DateTime? readingTime1;
...
Map<String, dynamic> toJson() => {
"value": value == null ? null : value,
"reading_time1": readingTime1 == null
? null
: "${readingTime1!.year.toString().padLeft(4, '0')}-${readingTime1!.month.toString().padLeft(2, '0')}-${readingTime1!.day.toString().padLeft(2, '0')}",
};
}
https://github.com/chunlee-thong/dart-quicktype Give this a try if it fits your use case
可以看看我提交的PR,现在等待官方合并，#1904 You can take a look at the PR I submitted, now waiting for the official merge。#1904
https://github.com/chunlee-thong/dart-quicktype/tree/dev 如果它适合您的用例，请尝试一下 Good job. That's what I need.Thank you
https://github.com/chunlee-thong/dart-quicktype/tree/dev Good job. That's what I need. Thank you @chunlee-thong
I was also suprised to find, that quicktype did not adapt their tool for a year now.
Instead of just replacing the @required by required, you removed it entirely, while ignoring that this is also invalid dart code, when sound null-safety is enabled?
Right now, the dart generation is almost unusable, since pretty much every dart code was moved to sound null safety in this time...
I would also love some null-safety support, however there is a workaround: you can add // @dart=2.9 at the top of your generated file, then you will be able to use it in your project (Note: you will still need to run and build your app with the --no-sound-null-safety check and null checks won't properly work on your generated types).
I would also love some null-safety support, however there is a workaround: you can add
// @dart=2.9at the top of your generated file, then you will be able to use it in your project (Note: you will still need to run and build your app with the--no-sound-null-safetycheck and null checks won't properly work on your generated types).
I dont think this is a valid option. In dart, one would usually use generated files as part to add additional functionality. For this one would have to migrate the whole project. Besides, after a year of stable sound null-safety for dart, this should be properly supported, as the default.
I would also love some null-safety support, however there is a workaround: you can add
// @dart=2.9at the top of your generated file, then you will be able to use it in your project (Note: you will still need to run and build your app with the--no-sound-null-safetycheck and null checks won't properly work on your generated types).I dont think this is a valid option. In dart, one would usually use generated files as
partto add additional functionality. For this one would have to migrate the whole project. Besides, after a year of stable sound null-safety for dart, this should be properly supported, as the default.
Yes, I agree, this is not a solution, just a workaround and this should be fixed, however this project doesn't seem to be maintained anymore and I don't know of any alternative, so it's the only thing we have.
Also, I don't know what you mean by "migrate the whole project". Those 2 changes (adding // @dart=2.9 comment to your types file and adding --no-sound-null-safety flag to your scripts) are the only ones needed for this to (somewhat) work.
Also, I don't know what you mean by "migrate the whole project". Those 2 changes (adding
// @dart=2.9comment to your types file and adding--no-sound-null-safetyflag to your scripts) are the only ones needed for this to (somewhat) work.
And to the toolsets that use your dart code (flutter) and to the projects that want to use your library or any other place that has an import. You essentially migrate your project to a Dart 2.10 project with the --no-sound-null-safety flag.
There's a reason why pub.dev has a chip-indicator/flag for libraries with sound null safety, you generally dont wanna mix the two. and 95% of dart code currently written will want to support sound null safety.
And to the toolsets that use your dart code (flutter) and to the projects that want to use your library or any other place that has an import.
Ahh yeah, you're right, it's probably not a good workaround for libraries, only applications.
why is the dart community so vehemently ignored in this project? its disheartening.
Well, comments like these aren't going to help
why is the dart community so vehemently ignored in this project? its disheartening.
Well, comments like these aren't going to help
Disagree. People should be aware that Quicktype as a whole is practically abandonware at this point. While everyone should be grateful for the free, open-sourced code, it's still polite for the authors to mark a project as unmaintained/archived, so people don't create a dependency on it if they're not expecting obvious issues like these.
I was someone who didn't notice, created a dependency on it, and am now spending my time trying to patch it instead of working on my projects.
