-
Notifications
You must be signed in to change notification settings - Fork 4.2k
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
Popover: enable auto-updating every animation frame #43617
Conversation
Size Change: -67 B (0%) Total Size: 1.24 MB
ℹ️ View Unchanged
|
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! Thanks for exploring an alternative fix.
A note about performance, in testing the toolbar/popover position is laggier when scrolling if a toolbar dropdown (like the block settings menu) is open, but I don't notice any difference if toolbar dropdowns are closed.
I think it's more important to fix the bug right now, and then look at performance separately, so it'd be good to move ahead with merging this.
6701a22
to
d164ae8
Compare
Just rebased this PR, will merge once CI is ✅ Regarding performance, I didn't really spot increased lagginess, but I really didn't do much testing on that, as I focused on fixing the bugs. Once this PR gets merged, I should be able to work on #43335, which hopefully may bring some perf improvements 🤞 although the "real" fix will be to improve cross-document support directly in |
This PR seems to have broken the draggable block e2e tests, I'll see if I can make the test work — otherwise I will open a PR that will partially undo the changes from this PR |
update | ||
update, | ||
{ | ||
animationFrame: true, |
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 noticed that you did some follow-up work to this, so I was wondering if this is still necessary. The reason I'm asking is because this line is a source of a large impact on performance degradation potentially.
It now happens in the "select" and "inserter open" metrics after this PR #42722 but it can also happen I guess for other interactions when there's a big list of popovers.
So can we remove it or is it still necessary? Are there alternatives?
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 guess this can be opt-in (or opt-out). However, I think it's generally a bad practice to render a large list of popovers at the same time. The performance regression in #42722 is a bit extreme that we render 1000 empty paragraphs in the test, but I do think we can refactor it in a follow-up to improve this.
From the floating-ui doc:
This is optimized for performance but can still be costly.
This option should be used sparingly...
I guess it makes sense to make it an opt-in in the next major release?
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 was introduced mainly to fix #42725, I expect that bug (and any other nested popover) to happen again if we undo this change — maybe it could be just enabled for the block toolbar?
While I agree that calling the getBoundingClientRect
function every animation frame is not ideal, I would also argue that the main reason while this can be a noticeable regression is that we're rendering hundreds of popovers at the same time.
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.
It turned out that the main issue for the performance regression is not this, so I'm ok not doing anything here and keeping it as but we should keep an eye on this any way as mentioned on their docs.
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.
Sure, makes sense
Dev note
See the dev note in #44195
What?
Fixes #42725
This PR changes the way
floating-ui
auto-updates the popover's position by enabling theanimationFrame
option. This means that the popover position is recalculated every animation frame (see the docs for more details).This has a few benefits:
__unstableObserveElement
prop (and the associatedMutationObserver
) are not necessary anymore, and can be removedscroll
event listener added to theiframe
is not necessary anymore, and can be removedWhy?
Currently, the
Popover
element adds some custom event listeners to the anchor and itsonwerDocument
when the anchor is in a different document from the popover (i.e. in an iframe, which is the case for the block toolbar in the site editor).These events don't cover all edge cases, and are therefore prone to causing regressions when other parts of the
Popover
are updated.How?
By setting the
animationFrame
option totrue
when calling theautoUpdate
function fromfloating-ui
What is not included in this PR
The changes in this PR were inspired by the work done in #43335, but I've deliberately decided to keep this PR as small as possible to make it easier to review.
I plan on iterate on
Popover
improvements in #43335, where I'm exploring / going to explore the following ideas:autoUpdate
only as part of theuseFloating
function call (and not in theuseLayoutEffect
hook, like it is at the moment)Popover
component update correctly and more frequently in more scenarios (e.g. prop change, ref changes...)reference
within the sameuseLayoutEffect
where the reference itself is computedResizeObserver
instead of listening to theresize
eventownerDocument
Testing Instructions
Check that the remaining popovers behave as expected, without any regressions..
Screenshots or screencast
Kapture.2022-08-25.at.16.18.14.mp4