-
Notifications
You must be signed in to change notification settings - Fork 29.7k
AnimatedValue<T> for implicit animations
#154378
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
Conversation
examples/api/lib/widgets/implicit_animations/animated_value.0.dart
Outdated
Show resolved
Hide resolved
|
I personally think the It could be a bit confusing to have an abstract class named |
|
Thanks @PurplePolyhedron!
100% agree. I've been using this branch to work on my own Flutter project and was surprised at how often I used some variation of that constructor.
I understand that this likely won't happen, but my preference would be to change those stream builder classes instead. The style guide has a rule to encourage grouping constants under a class name rather than having them in the global namespace, and I'm a huge fan, since it makes autofill suggestions much less cluttered. The disadvantage of turning a generative constructor into a factory is that you're no longer able to extend the class. But for "builder" classes, you'd never want to do it anyway: class MyWidget extends Builder {
MyWidget({super.key})
: super(builder: (context) {
return Column(children: [
// ...
]);
});
}Extending I personally feel that organizing builder classes as constructors under the same namespace (like how |
goderbauer
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.
AnimatedValue<T> looks like a nice simplification.
examples/api/lib/widgets/implicit_animations/animated_value.0.dart
Outdated
Show resolved
Hide resolved
examples/api/lib/widgets/implicit_animations/animated_value.0.dart
Outdated
Show resolved
Hide resolved
examples/api/lib/widgets/implicit_animations/animated_value.0.dart
Outdated
Show resolved
Hide resolved
examples/api/lib/widgets/implicit_animations/animated_value.0.dart
Outdated
Show resolved
Hide resolved
examples/api/lib/widgets/implicit_animations/animated_value.0.dart
Outdated
Show resolved
Hide resolved
examples/api/lib/widgets/implicit_animations/animated_value.0.dart
Outdated
Show resolved
Hide resolved
80adf1d to
4302178
Compare
This comment was marked as resolved.
This comment was marked as resolved.
1f04564 to
9bdf679
Compare
|
Okay, here is a naming scheme that I'm decently happy with:
I've changed the base
|
nate-thegrate
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.
Thanks for the review!
| } else { | ||
| from = value; | ||
| target = newTarget; | ||
| value = widget.lerp(from, target, 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.
The existing lerp() methods are set up with nullable parameters and a nullable return type, for example:
class Color {
static Color? lerp(Color? a, Color? b, double t) {
// ...
}
}The idea is that passing a non-null Color to a and b always gives a non-null output, but there's also an option to lerp to/from null, which could cause the output to be null.
Since this widget's value is non-nullable, we're guaranteed that the lerp function won't ever be passed a null argument, so the only way this could fail is with a user-defined callback that can return null based on non-null inputs.
handle the null case gracefully
That's a great idea—rather than a confusing "null-check operator used on a null value", we could have an assert with a useful message. I'll go ahead and add that, thanks!
examples/api/lib/widgets/implicit_animations/animated_value.0.dart
Outdated
Show resolved
Hide resolved
97e8d23 to
ace99c1
Compare
|
Marking as a draft, since I've made progress on flutter.dev/go/zero-rebuilds that has some overlap with this PR. Will hopefully get it figured out over the weekend! |
|
@nate-thegrate says he is still looking at this. |
ace99c1 to
5fd6d1f
Compare
|
An update, finally! 🥳 The plan is to break this addition into multiple PRs, starting with #160005. But feel free to leave any feedback regarding the overall direction here! |
|
It looks like this pull request may not have tests. Please make sure to add tests before merging. If you need an exemption, contact "@test-exemption-reviewer" in the #hackers channel in Discord (don't just cc them here, they won't see it!). If you are not sure if you need tests, consider this rule of thumb: the purpose of a test is to make sure someone doesn't accidentally revert the fix. Ask yourself, is there anything in your PR that you feel it is important we not accidentally revert back to how it was before your fix? Reviewers: Read the Tree Hygiene page and make sure this patch meets those guidelines before LGTMing. The test exemption team is a small volunteer group, so all reviewers should feel empowered to ask for tests, without delegating that responsibility entirely to the test exemption group. |
|
This pull request has been changed to a draft. The currently pending flutter-gold status will not be able to resolve until a new commit is pushed or the change is marked ready for review again. For more guidance, visit Writing a golden file test for Reviewers: Read the Tree Hygiene page and make sure this patch meets those guidelines before LGTMing. |
5fd6d1f to
1a1e65f
Compare
preparing for #154378 It'd be nice to clean up the implicitly animated widget logic, especially since it could make the upcoming PR easier to review.
|
This will likely be implemented as a separate package, unless a maintainer from the Flutter team recommends otherwise. |
This pull request has a few goals:
dynamicannotationsBefore
After
ValueAnimation is essentially "ValueNotifier but with smooth transitions".
Before
After
This API comes without an
AnimationController's boilerplate. TheMouseRegionno longer needs to rebuild at all, and when combined with #159757, the "build" stage of the pipeline can be skipped entirely after each animation tick.