-
Notifications
You must be signed in to change notification settings - Fork 15
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
VizPanel: Allow configuring hover header offset #674
Conversation
Hm, in the old architecture the grid was rendered withing a scroll wrapper too, what's the difference then between the DOM of the old and new arch? I don't think we should change the offset. |
Uhm, isn't that a matter of canvas-content not having top padding anymore? |
@dprokop Yes indeed, old arch had top padding of 16px and offset of -16px (to fill that padding). Currently we don't have padding on the canvas content and padding comes from controls above (which are sticky with high zIndex). We could add top padding of 16px and offset of -16px to mimic old arch would look like that: The only question is about how pretty this UX with that gap |
@Sergej-Vlasov noticed one more thing, in the old arch the offset is smaller for the panels at the top: So there must be a collision detection or sth? |
Check is based on position so offset is -16 if panel at the top and -32 if anything else
|
@dprokop Thinking of just passing through a |
@Sergej-Vlasov fixed a related bug grafana/grafana#85621 Not sure we can fix this only in buildGridItemForPanel without a behavior as you can move panels around and the offset would need to change |
Exactly. @Sergej-Vlasov we would need to add a behavior to That's why maybe there's an easier solution that does not require us to observe grid position. The same problem may appear in layouts other than Grid and then the current method won't work. I think we may want not to rely on the y-position, but rather the constraints of the scroll container. We already use https://floating-ui.com/docs/usefloating to position Tooltips and I think that's what we possibly would may want to use to position the hover header. They have a middleware that guarantees visibility: https://floating-ui.com/docs/shift Thoughts? |
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.
As we agreed, let's go for this one 👍
🚀 PR was released in |
Fixes #84830
Issue:
When
hoverHeader
is enabledPanelMenu
is being cropped. There are 2 issues:crop on subsequent panels due to descending z-index on the panelsSolution:
Set
hoverHeaderOffset
prop onPanelChrome
to prevent default offset of-32
inHoverWidget
Definitely not ideal because it covers viz data but its quite tricky to portal
HoverWidget
and keep accessibilityOpen to comments on this one.
📦 Published PR as canary version:
4.5.5--canary.674.8612605644.0
✨ Test out this PR locally via:
npm install @grafana/scenes@4.5.5--canary.674.8612605644.0 # or yarn add @grafana/scenes@4.5.5--canary.674.8612605644.0