Description
I've come across this in previous PRs and in a recent PR.
Take this as an example where Color? get selectedColor is nullable but MaterialStateColor.resolveWith doesn't allow returning a null value.
In a case where we need to return a null so an "effectiveColor" variable can fall back to a different color for the default property.
@override
Color? get selectedColor => MaterialStateColor.resolveWith((Set<MaterialState> states) {
if (states.contains(MaterialState.selected)) {
return _themeData.colorScheme.primary;
}
// cannot return a null.
return null;
});I would have to provide a condition to avoid getting Colors.transparent, like this.
@override
Color? get selectedColor => _themeData.colorScheme.primary;
/// ....
final Color? effectiveSelectedColor = MaterialStateProperty.resolveAs<Color?>(selectedColor, states)
?? MaterialStateProperty.resolveAs<Color?>(tileTheme.selectedColor, states)
?? MaterialStateProperty.resolveAs<Color?>(theme.listTileTheme.selectedColor, states)
?? (states.contains(MaterialState.selected) ? defaults.selectedColor : null);I've noticed this pattern throughout the framework where MaterialStateColor.resolveWith often resorts to Colors.transparent. I would like to make sure this doesn't go unnoticed if it is by design and if there is a way to return null.
Here are some instances:
flutter/packages/flutter/lib/src/material/menu_anchor.dart
Lines 3712 to 3719 in 921f077
flutter/packages/flutter/lib/src/material/checkbox.dart
Lines 844 to 856 in 921f077
flutter/packages/flutter/lib/src/material/slider.dart
Lines 1938 to 1950 in 921f077