You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When using a generic freezed object, the copywith implementation defaults fields to null which is incorrect since the type argument can be a nullable type which violates the feature of freezed: copyWith can set nulls.
// ...@pragma('vm:prefer-inline')
@override$Rescall({
Object? value =null,
}) {
return_then(_value.copyWith(
value:null== value
? _value.value
: value // ignore: cast_nullable_to_non_nullableasT,
) as$Val);
}
// ...
Which breaks usages such as
test('copy null', () {
const state =State<int?>(value:123);
// all goodexpect(state.value, 123);
// ugh-oh, that should work, but it does notfinal copied = state.copyWith(value:null);
expect(copied.value, null);
});
Expected behavior
The above copyWith with a null value should work, as previous versions of freezed worked like that and no such breaking change was stated in the changelog. Luckily when upgrading freezed in our project tests caught this issue.
Additional info
The problem originates from this #735 PR. I would argue, that the change with conditional null and freezed should be reverted. The speed gain is negligible and creates many edge cases, another example would be #803 which IMO is not a low priority bug since it broke existing code. The PR uses some e.isNullable to decide whether to use freezed or null, my educated guess would be that this only handles types which are explicitly marked as nullable but not those that can have instances which are null.
The text was updated successfully, but these errors were encountered:
Describe the bug
When using a generic freezed object, the copywith implementation defaults fields to
null
which is incorrect since the type argument can be a nullable type which violates the feature of freezed: copyWith can setnull
s.To Reproduce
I created a repo with the described bug and generated files: https://github.com/shilangyu/freezed-copywith-null
Here is a summary:
Given a freezed object
The generated copyWith defaults to
null
Which breaks usages such as
Expected behavior
The above copyWith with a null value should work, as previous versions of freezed worked like that and no such breaking change was stated in the changelog. Luckily when upgrading freezed in our project tests caught this issue.
Additional info
The problem originates from this #735 PR. I would argue, that the change with conditional
null
andfreezed
should be reverted. The speed gain is negligible and creates many edge cases, another example would be #803 which IMO is not a low priority bug since it broke existing code. The PR uses somee.isNullable
to decide whether to usefreezed
ornull
, my educated guess would be that this only handles types which are explicitly marked as nullable but not those that can have instances which arenull
.The text was updated successfully, but these errors were encountered: