-
Notifications
You must be signed in to change notification settings - Fork 36
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
STCOM-1282. Multiselection overlay overlapping input under certain conditions. #2269
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.
I really appreciate the detail in the PR description. It would have been impossible to tell what was going, or why this is necessary without it. Thank you!
|
…nditions. (#2269) * if renderToOverlay is used, set the boundary to the overlay container * log changes
The positioning of
<MultiSelection/>
's overlay element is completely controlled by thepopper
library. To affect the placement at the instance level,popper
's options include an object with 'modifiers' - a bunch of different adjustments that are applied/accounted for when the overlay element is rendered. One of them is 'preventOverflow' that keeps an element within the bounds of a certain scrollable parent/element. It defaults to thescrollParent
of the input the overlay belongs to.The case sited in STCOM-1282 has
<MultiSelection>
being used within a *short<EditableList>
. ThescrollParent
- theMCL
's scrollable element - with only 3 items is not tall enough to render the overlay without it overlapping the<MultiSelection>
control. TherenderToOverlay
prop is used as it should be on theMultiSelection
, butpopper
still wants to stick to MCL's scrollable element as its boundary.Approach
This PR changes the setting applied to
popper
iin<MultiSelection>
if therenderToOverlay
prop is used, setting theboundaryElement
of thepreventOverflow
modifier to thediv#OverlayContainer
rendered within the stripes UI.