-
Notifications
You must be signed in to change notification settings - Fork 29.7k
make CupertinoDynamicColor const constructible #39430
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
make CupertinoDynamicColor const constructible #39430
Conversation
| : CupertinoUserInterfaceLevelData.base; | ||
|
|
||
| Color resolved; | ||
| switch (brightness) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I was expecting a much larger switch statement
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah with only eight possibilities (at least for now) it isn't too bad. It is a bit verbose, but I think it gains a lot in clarity.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am scared of enums and switches, especially when the enum has a name like CupertinoUserInterfaceLevelData
justinmc
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
It's great that you were able to make this const. Did you find that it needed to be const for some reason or are you just doing it because it's possible?
| elevatedColor, | ||
| darkElevatedColor, | ||
| highContrastElevatedColor, | ||
| darkHighContrastElevatedColor, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this is a lot more clear 👍
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Indeed. Nice!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👏
| highContrastColor: color2, | ||
| darkHighContrastColor: color3, | ||
| )); | ||
| ) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Comma here?
|
@justinmc default values have to be const values, if a widget's constructor has a color parameter with a default color, it can't take a
|
| assert(highContrastElevatedColor != null), | ||
| assert(darkHighContrastElevatedColor != null), | ||
| assert(_effectiveColor != null), | ||
| super(0); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A // comment that refers to the value getter would be useful here.
| }(), 'The colorMap provided is invalid: $_colorMap'), | ||
| super(value.value); | ||
| @override | ||
| int get value => _effectiveColor.value; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
NICE
| resolved = isHighContrastEnabled ? highContrastColor : color; | ||
| break; | ||
| case CupertinoUserInterfaceLevelData.elevated: | ||
| resolved = isHighContrastEnabled ? highContrastElevatedColor : elevatedColor; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
add a perfunctory break here
| if (identical(this, other)) | ||
| return true; | ||
|
|
||
| return other.runtimeType == runtimeType |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe check for identical(this, other) first?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It already does.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry, yes it does! Hazards of looking through the github review microscope.
| // Fallback System Colors, extracted from: | ||
| // https://developer.apple.com/design/human-interface-guidelines/ios/visual-design/color/#dynamic-system-colors | ||
| // and iOS 13 beta. | ||
| const CupertinoSystemColorsData _kSystemColorsFallback = CupertinoSystemColorsData( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
const!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure this is entirely safe. Not sure if developers should expect it either (we're not documenting this case). If resolved.runtimeType != value.runtimeType do we still want to do this? Seems like it would be easier to understand the semantics of thie method if we unconditionally returned a CupertinoDynamicColor (not a subclass).
darrenaustin
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM. Nice update. Having a const constructor for a class like this is helpful and the changes to the color storage are a lot easier to follow.
| elevatedColor, | ||
| darkElevatedColor, | ||
| highContrastElevatedColor, | ||
| darkHighContrastElevatedColor, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Indeed. Nice!
| : CupertinoUserInterfaceLevelData.base; | ||
|
|
||
| Color resolved; | ||
| switch (brightness) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah with only eight possibilities (at least for now) it isn't too bad. It is a bit verbose, but I think it gains a lot in clarity.
823fa8c to
2ab56b8
Compare
HansMuller
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
Description
make
CupertinoDynamicColor's constructors const, in order to use aCupertinoDynamicColoras the default value of a function argument. This change would allow us to provide a defaultCupertinoDynamicColorin the constructor of the following widget, without breaking its current API:Checklist
Before you create this PR confirm that it meets all requirements listed below by checking the relevant checkboxes (
[x]). This will ensure a smooth and quick review process.///).flutter analyze --flutter-repo) does not report any problems on my PR.Tests
No new tests were added: existing tests should be able to cover this.
Breaking Change
Does your PR require Flutter developers to manually update their apps to accommodate your change?