-
Notifications
You must be signed in to change notification settings - Fork 29.7k
Add a hook for scroll position to notify scrolling context when dimen… #87076
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
Piinks
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.
I think i can make use of the scroll notification to do the job, but I more toward to add this as a call back because the scrollable is strictly tied to a scroll position and not any arbitrary scroll position below its widget sub tree, plus there is one frame delay for it If the strategy is to avoid adding new api to scroll context and use notification system when it is possible. I can switch to use the notification instead |
|
I think we still have to figure out whether to add the new api or use the scrollmetrics notification, I currently more toward adding the api See my previous comment. |
Piinks
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.
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.
Can we just add documentation for ScrollMetricsNotification here and vice versa - add documentation for this in ScrollMetricsNotification. I think having two separate APIs is ok, because they have very different uses. We may want to also say when they may be preferred, like if you want to listen for this change, choose the other one.
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 just a little worried, because this api will be called in the layout stage, which will greatly restrict the application scenario, such as the tree cannot be rebuilt, and in the case of lazy loading, it will be called multiple times in the same frame.
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.
That is actually a good point, let me think about this more
chunhtai
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.
updated to use notification, PTAL @Piinks @xu-baolin
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.
@xu-baolin @Piinks
any reason we don't want to send when it initialize for the first time?
My use case here is the render object listens to the scrollable metrics before it applies content dimensions for the first time, it wants to be notified when the scrollable metrics initialize.
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.
If this doesn't make sense, we probably need a hook, something like didInitializeScrollMetrics
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.
There is no special reason, it's just that we didn't find the necessary scene at the time. If you need it, I think we can do it.
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 post #87421 to land this change.
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 we should check the depth of the events.
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.
can you elaborate?
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.
ah I see what you meant
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.
Oh,you already checked the context, I think it have the same effect.
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 use depth is safer since another scrolling context can target the same notification context, that is a weird case if that happens though
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.
This is intended change, right?
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.
yes, now it takes one more frame to update the semantics
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.
You just need updates the semantics at the first initial metrics?
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.
no and subsequence changes as well, we just lucky that scroll metrics change usually come with scroll position changes (which will usuaully cause semantics update) so it wasn't so obvious before.
without the this pr, the semantics for the first frame is always wrong, but we are lucky that usually gets update due to some other semantics changes from the modal route.
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.
Got it.thanks for your explanation.
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.
@Piinks Since now the first scroll metrics initialize will call fadeoutanimationcontroller.forward(), the error may throw multiple times
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 probably won't need the first empty scroll event request now.
|
@Piinks @xu-baolin PTAL 🍡 |
|
Just waiting on the scroll metrics change to roll, there were some failing tests but I think I have them all fixed. Also, CI is unhappy here. |
Thanks 😄 |
|
Update: we are still waiting on the scroll metrics PR to roll. |
Piinks
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!

The scrollable needs to know if the content dimensions in the scroll position has changed in order to update its semantics node correctly. This pr adds an API to ScrollingContext to listen to the change.
fixes #40419
Pre-launch Checklist
///).If you need help, consider asking for advice on the #hackers-new channel on Discord.