-
Notifications
You must be signed in to change notification settings - Fork 234
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
Fix implicit animationg bug #262
Conversation
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.
Makes sense!
@brynbodayle I fixed another (related) issue with pinned days of the week. I was drawing them at weird positions due to the whole 3x visible bounds thing that I added for animated layout passes. The 2 new commits fix that + add unit tests for it. |
@@ -242,7 +248,7 @@ final class VisibleItemsProvider { | |||
|
|||
// Handle pinned day-of-week layout items | |||
if case .vertical(let options) = content.monthsLayout, options.pinDaysOfWeekToTop { | |||
handlePinnedDaysOfWeekIfNeeded(yContentOffset: bounds.minY, context: &context) | |||
handlePinnedDaysOfWeekIfNeeded(yContentOffset: offset.y, context: &context) |
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.
we don't want to use the extended bounds for this, otherwise we'll render these pinned items off screen
Details
This fixes an issue that could cause the calendar to layout with an odd animation. Recently, we changed the way
layoutSubviews
works - we check if we're currently in an animation closure, and if we are, we layout a larger region than what's currently visible so that offscreen items animate in / away correctly.This behavior change only makes sense if the reason we're in
layoutSubviews
is because of a call tosetContent
(which will do some animation preparation). If we end up inlayoutSubviews
in an animation closure withoutsetContent
getting called first, then we didn't do any animation preparation insetContent
, and the newlayoutSubviews
behavior doesn't make sense anymore.The solution is to set a flag in
setContent
to indicate that the next call tolayoutSubviews
should use the new behavior for animated updates, rather than checking if we're in an animation closure (which could happen if a random part of code callslayoutIfNeeded
in an animation closure without also callingsetContent
first).Related Issue
N/A
Motivation and Context
Found a bug in the Airbnb app
How Has This Been Tested
Example app, Airbnb app
Types of changes
Checklist