-
Notifications
You must be signed in to change notification settings - Fork 28.7k
CupertinoPicker
new onChanged behaviour
#170202
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
base: master
Are you sure you want to change the base?
Conversation
I might try to also make these changes for CupertinoDatePicker depending on how this one goes. |
444ee7b
to
2a3529b
Compare
@@ -89,6 +89,7 @@ class CupertinoPicker extends StatefulWidget { | |||
this.magnification = 1.0, | |||
this.scrollController, | |||
this.squeeze = _kSqueeze, | |||
this.changeReportingBehavior = ChangeReportingBehavior.onScrollUpdate, |
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.
Thanks for trying to land this with as little breakage as possible. I'm guessing having it default to onScrollUpdate is because of this comment? Although since the goal is to match native we might have to just break directly. I'm not really sure how to proceed, @MitchellGoodwin what do you think?
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.
Haven't seen that comment, actually.
My hunch is that, even though the current behaviour is a "bug", some folks might have had some logic built around it, so I didn't want to outright break it.
It's your call, I'm fine with any decision.
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.
In my opinion, have it default to the non-breaking behavior, and call out that the default behavior is the other enum option in the documentation. When this reaches stable, we can recommend setting the enum to the right value to get native behavior, then if we change the default after that we'll have given warning, and we can possibly do a dart fix. Changing the functional behavior suddenly is a little dangerous, and easy to miss in communications.
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.
Since it is a new optional parameter, I am not sure that folks will notice a change in the documentation that doesn't force them to do something to acknowledge the new behaviour.
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.
They might miss it, yes. But we can highlight it in the release blog and breaking change guides before it's made default to create some resources. Mentioning it in the docs is more for helping with a migration and future understanding, rather than informing the developers that a breaking change is happening.
03015bc
to
0affb5c
Compare
0affb5c
to
58a7d25
Compare
This PR adds a new behaviour to
ListWheelScrollView
that allows to switch between reporting changes on scroll update or only on scroll end.CupertinoPicker
now has achangeReportingBehavior
param that forwards toListWheelScrollView
.New behaviour is a breaking change if set as default, so I have added the
changeReportingBehavior
param to opt-in. My idea is that it can be marked asDeprecated
immediately and then removed fromCupertinoPicker
later or we can just leave the param there and make it more customizable.I am open to other ideas on how to land this without breaking clients.
Fixes #170201
Pre-launch Checklist
///
).