-
Notifications
You must be signed in to change notification settings - Fork 28.7k
Newly constructed tweens should have same begin and end #94363
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
a7c5b3d
to
23438c4
Compare
Failing checks will be fixed once #94601 is merged. |
This pull request executed golden file tests, but it has not been updated in a while (20+ days). Test results from Gold expire after as many days, so this pull request will need to be updated with a fresh commit in order to get results from Gold. 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. |
@@ -430,6 +430,8 @@ abstract class ImplicitlyAnimatedWidgetState<T extends ImplicitlyAnimatedWidget> | |||
tween ??= constructor(targetValue); | |||
if (_shouldAnimateTween(tween, targetValue)) | |||
shouldStartAnimation = true; | |||
else | |||
tween.end ??= tween.begin; |
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 don't think this is correct. For some tweens (e.g. ColorTween, https://master-api.flutter.dev/flutter/animation/ColorTween-class.html) null has a special meaning. And as documented in https://master-api.flutter.dev/flutter/animation/Tween-class.html under "Nullability" that's totally ok.
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 understand that.
- I haven't removed the ability for the value to be
null
. I'm just making sure that when the tween should not animate, begin and end should be the same, as there is no animation. This adds to a state of being unanimated. - In the current implementation of
ImplicitlyAnimatedWidget
, it is not possible to animate from non-null color to null anyway, as when the color (akatargetValue
) becomes null, the tween is set to null, ignoring it. As a matter of fact, this is something that needs to be fixed too. - Lastly,
ImplicitlyAnimatedWidget
should be agnostic of what should happen whentargetValue
becomes null. Current extensions ofImplicitlyAnimatedWidget
are trying to expect different things from it. Example:AnimatedContainer
has a nullablealignment
argument which is supposed to be ignored when it is null, which makes its tween null. WhereasAnimatedColor
(fictional widget working overColorTween
) has a special meaning when itscolor
is null, meaning its tween should remain non-null and haveend
set to null.
Possible solution:
- The
tween
s' nullability should be handled byImplicitlyAnimatedWidget
's extension instead of itself. - The check for whether a tween should animate or not, should depend only on its current
end
, even it it's null.bool _shouldAnimateTween(Tween<dynamic> tween, dynamic targetValue) { return targetValue != tween.end; }
- From the perspective of
ImplicitlyAnimatedWidget
,targetValue
being null should be considered as one of the valid tween states instead of using it to null the tween.
From the user's perspective, whatever value (null or non-null) is passed to forEachTween
, the tween will animate to it. If I wish to ignore it, I should make the tween null themselves.
@werainkhatri This is still blocked on #94601 getting fixed first? |
@goderbauer no, this is separate now. i have listed my findings in the conversation above. do let me know what you think. |
OK. Can you rebase this to the latest master and make sure that all checks pass? Thanks! |
23438c4
to
4ed992c
Compare
4ed992c
to
6973474
Compare
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
Looks like this was blocked due to #94601 @goderbauer do you mind taking a look at the |
Retriggered the check, let's see what happens. |
Fails again :( |
I triggered it again. Hopefully it will pass. There were some technical problems with the check last week. |
Still failing... |
FIxes a bug where when a tween is constructed (was null before), after the implicit animated widget has animated at least once, the newly constructed tween has
end = null
. The widget is not animated, as the tween has just been constructed (shouldAnimate = targetValue != (tween.end ?? tween.begin)
) and hence not updated. But theanimation.value
is 1.0 (as it has been animated once before). So, when this tween is evaluated againstanimation.value
, it throws an error.The fix is to set the
tween.end
of every newly constructed tween totween.begin
.fixes #84258
Pre-launch Checklist
///
).If you need help, consider asking for advice on the #hackers-new channel on Discord.