Currently, if a field is nullable, it is not required in the constructor of that class. I think while this is useful for DTOs, it can be a source of bugs for CQRS types. I think I'd rather pass an explicit null.
Nullability ≠ Optionality
Why?
When a field is nullable (lets say T?), it does not mean it only accepts a non-nullable T and a constant null. Instead, it means you can pass a variable that is possibly null. This is an important distinction, it means you always should pass a variable, but this variable just might happen to be null. In a customer project this has already been a problem, where a simple mistake of forgetting to pass a value to a nullable CQRS method field caused problems in the whole system afterwards.
Example of the change proposed
class Something implements Query {
Something({
- this.field1,
+ required this.field1,
required this.field2,
});
final String? field1;
final int field2;
}
Currently, if a field is nullable, it is not
required
in the constructor of that class. I think while this is useful for DTOs, it can be a source of bugs for CQRS types. I think I'd rather pass an explicitnull
.Nullability ≠ Optionality
Why?
When a field is nullable (lets say
T?
), it does not mean it only accepts a non-nullableT
and a constantnull
. Instead, it means you can pass a variable that is possibly null. This is an important distinction, it means you always should pass a variable, but this variable just might happen to be null. In a customer project this has already been a problem, where a simple mistake of forgetting to pass a value to a nullable CQRS method field caused problems in the whole system afterwards.Example of the change proposed