-
Notifications
You must be signed in to change notification settings - Fork 4.3k
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: tidy up and improve shifting behavior #42531
Conversation
Size Change: +105 B (0%) Total Size: 1.27 MB
ℹ️ View Unchanged
|
return offsetMiddleware( ( { placement } ) => { | ||
const computedMainAxis = getMainAxisFromPlacement( placement ); | ||
return { | ||
mainAxis: computedMainAxis === 'x' ? -top : -left, |
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 there are a couple of fixes to be made here. If the main axis is x
(horizontal), the offset should be left
(also horizontal).
I think the problem is that getMainAxisFromPlacement
is returning the wrong value. From the docs, the main axis is the one on which the distance between the reference and floating elements would be measure, so for a top
or bottom
placement you'd measure along the y
axis.
I also noticed in #42417 that for top
and left
placements, the offset needs to be subtracted on the main axis, and for right
and bottom
placements added.
When that's all addressed, the code will be very similar to #42417, so perhaps it's worth reviewing/merging that PR? I tested it pretty thoroughly on a range of placements.
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.
When that's all addressed, the code will be very similar to #42417, so perhaps it's worth reviewing/merging that PR? I tested it pretty thoroughly on a range of placements.
That is definitely true, although this PR also adds a more refined behavior to limitShift
, and several other minor improvements.
Probably the best course of action is to review / merge #42417 and then rebase this PR and refine the limitShift
approach ?
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.
Sounds good to me, thanks 👍
84cefba
to
36c0d69
Compare
I rebased to better check things as this PR affects some popovers placement. |
36c0d69
to
1102825
Compare
Is this one ready for review @ciampo? |
Not yet, but I plan on marking it as such by Wed EOD |
…the anchor s virtual reference
1102825
to
355333b
Compare
I actually decided to split the work done in this PR across a few smaller, more focused PRs:
I'm going to close this PR, we can continue the conversation in the smaller PRs. |
Opened #43186 with fixes to the animation origin |
What?
The main changes in this PR are:
frameOffset
middleware to use theoffset
middleware instead of manually adding upx
andy
coordinateslimitShift()
floating UI's option, in order to allow the floating element to fully shift past its reference when scrolling down in the site editor__unstableForcePosition
propuseLayoutEffect
hook in thePopover
componentPopover
worksYou can refer to the individual commits for an easier review of the changes.
Why?
(partially) fixes the regression flagged in #41575
alternative approach to #42417 and #42521
How?
Testing Instructions
So far, I've only tested these changes with the block toolbar in the site editor and post editor.
We should definitely test more throughly and across all different popover usages, but first I'd first like to establish if this is a potentially good approach, before investing more time in it
Screenshots or screencast
Kapture.2022-07-19.at.14.20.06.mp4