[Dashboard] Focus on a single panel#165417
Conversation
|
Do we want to disable controls, editor toolbar, and/or unified search access when focused on a single panel as well? |
When editing the panel settings it doesn't make much sense to filter visualizations but they don't hurt either so I would leave them accessible for now. In the future, we can reopen the discussion when users are able to edit panel-level filters from there. Accessing the filters, controls, etc. definetely makes more sense when users are editing a visualization, @stratoula is it fine for ESQL visualizations? I think this doesn't work in Discover now. |
|
@teresaalvarezsoler not sure I have understood the question correctly but I will give it a shot. We have disabled the kql bar and the filter builder in Discover as you can do all these things with ES|QL. On a dashboard, where we don't have the ES|QL editor we have left the kql bar/filter builder which work fine with dataview and ESQL charts. With that being said, it makes sense to me to not disable these elements when inline editing a visualization. |
|
Great, then let's leave them accessible @cqliu1 |
|
RE: a11y, it looks like even though mouse events are disabled for the blurred panels, you can still tab over to the buttons in the blurred panels before reaching the flyout. Do we want to prevent keyboard navigation to the blurred panels? If so, is this a blocker, or can we improve a11y in a follow up PR? |
|
Pinging @elastic/kibana-presentation (Team:Presentation) |
I've disabled the editor toolbar while a panel is focused, but I'll leave controls accessible.
|
@andreadelrio With Devon's changes mentioned above that remove the debounce from overlays, opening and closing the flyout looks much smoother. |
|
In 3f02e1a, I figured out a way to programmatically remove blurred panels and nested elements from the tab order to disable keyboard navigation. Sep-20-2023.11-29-16.mp4 |
|
@elastic/appex-sharedux I'm not sure why you weren't automatically listed as a reviewer, but I enabled the |
ThomThomson
left a comment
There was a problem hiding this comment.
Changes LGTM! Tested this in chrome, and everything looks good (especially the tab ordering). Also looked through the changes, and left one nit.
Additionally, can you think of a good way to test this, preferably with unit tests? Maybe checking for the presence of a class or a data test subj when focus panel is defined?
| isDisabled?: boolean; | ||
| } | ||
|
|
||
| export const ControlsToolbarButton: FC<Props> = ({ controlGroup, isDisabled }) => { |
There was a problem hiding this comment.
nit: why the use of FC here? Using FC like this implicitly adds the children prop, and this toolbar button doesn't actually take children. It's also a little cleaner to just declare the Props type inline instead of naming it.
| // https://github.com/react-grid-layout/react-grid-layout/issues/1241#issuecomment-658306889 | ||
| children, | ||
| className, | ||
| style, |
There was a problem hiding this comment.
What was style used for? Nothing?
sebelga
left a comment
There was a problem hiding this comment.
Shared ux changes LGTM 👍
|
|
||
| return ( | ||
| <div | ||
| style={{ ...style, zIndex: focusedPanelId === id ? 2 : 'auto' }} |
There was a problem hiding this comment.
@ThomThomson Before style was destructured from props to override z-index on focusedPanelId which wasn't being used, and it doesn't seem necessary to change the z-index, so I removed the z-index style and removed the style previously destructured on line 46.
If style is passed in as a prop to this component, it will still be spread onto this div with the rest of the props.
andreadelrio
left a comment
There was a problem hiding this comment.
LGTM, thanks for the updates. Nice job on this!
|
Can the menu item start with a verb, for example "Apply settings", so that it follows the format of the other items in the menu? |
@gchaps I'm not sure We renamed from |
|
After talking with @cqliu1, we decided on |
💚 Build Succeeded
Metrics [docs]Async chunks
Page load bundle
History
To update your PR or re-run it, just comment with: |




Summary
Closes #163274.
This adds support for focusing a single panel on a dashboard while blurring/disabling all other panels.
Aug-31-2023.15-25-11.mp4
All interactions on blurred panels are disabled as well as any layout changes on either the focused or blurred panels, but the user still has access to controls, the editor toolbar, and unified search.
Note: For testing purposes, I have the focus behavior implemented with the
Panel settingsaction, but I won't merge this PR with focus enabled forPanel settings. This behavior is meant for flyouts with inline editing capabilities, like the future ESQL inline editor flyout where changes apply in real-time without hittingApplyto see the changes.Checklist
Delete any items that are not applicable to this PR.
Risk Matrix
Delete this section if it is not applicable to this PR.
Before closing this PR, invite QA, stakeholders, and other developers to identify risks that should be tested prior to the change/feature release.
When forming the risk matrix, consider some of the following examples and how they may potentially impact the change:
For maintainers