-
Notifications
You must be signed in to change notification settings - Fork 8.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
[Uptime] Move uptime actions to Header Actions Menu #100298
[Uptime] Move uptime actions to Header Actions Menu #100298
Conversation
6f53c56
to
54d981b
Compare
54d981b
to
c6f4e54
Compare
Pinging @elastic/uptime (Team:uptime) |
}; | ||
export const ActionMenu = ({ appMountParameters }: { appMountParameters: AppMountParameters }) => ( | ||
<HeaderMenuPortal setHeaderActionMenu={appMountParameters.setHeaderActionMenu}> | ||
<ActionMenuContent /> |
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.
There weren't any test for these button controls, so I added some while I was in here. I extracted this content to a new component because we don't have much interest in testing the HeaderMenuPortal
API.
@elasticmachine merge upstream |
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.
Looks great!
One thing I noticed, is that each one of the header options is wrapped in a button, but the actual action is nested inside and may be either a button or a link. This is causing some keyboard navigation and screenreader issues, as each option can be tabbed to twice.
When a button is nested inside a button, the first tab will read out the content, but when you attempt to use the keyboard for clicking it does nothing, since the wrapper button doesn't contain an onclick. Then on the second tab it rereads the content, and at that time you can use the keyboard to click the button.
For the Settings and Analyze data links however, the experience is even more difficult. The first tab once again reads the button content, but i clicking does nothing due to a lack of an onclick handler. Then once you tab again, you land on the link which is read out, but the button content and instructions for clicking the button are again read. However, since this is a link, the instructions for how to actually "press" the link are incorrect, and following the screenreader instructions will result in nothing happening. Instead, you have to press the enter key to access the link.
We may need to revisit wrapping each of these options in an empty button, and instead unnest the elements that contain the actual behavior and use some other component to maintain style consistency.
x-pack/plugins/uptime/public/components/common/header/action_menu_content.test.tsx
Outdated
Show resolved
Hide resolved
<EuiToolTip position="top" content={<p>{ANALYZE_MESSAGE}</p>}> | ||
<EuiButtonEmpty | ||
aria-label={i18n.translate('xpack.uptime.page_header.exploratoryLink.label', { | ||
defaultMessage: 'Navigate to the exploratory view to visualize data', |
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 believe the user facing name is current 'Analyze Data'.
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.
Had another pass at this, how is this looking? 1c9d3e7
I've addressed the smaller items; working on the nested button issue now. |
it('renders settings link', () => { | ||
const { getByRole, getByText } = render(<ActionMenuContent />); | ||
|
||
const settingsAnchor = getByRole('link', { name: 'Navigate to the Uptime settings page' }); |
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 usually avoid getByRole
they tends to be slow.
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.
Was added as a response to feedback.
})} | ||
iconType="gear" | ||
> | ||
<FormattedMessage id="xpack.uptime.page_header.settingsLink" defaultMessage="Settings" /> |
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.
@justinkambic @formgeist have we decided on the order of buttons? in APM settings comes before Alerts. Here alerts is before Settings, we should use same order for same kind of buttons.
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.
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.
@shahzad31 @justinkambic The correct order is described in the latest issue that relates to the menu options #99902
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 was following the screenshot in the issue. I prefer to not have settings be the first thing in the list because I tend to not think of Settings as the most important item in nav menus, but I agree we need to have uniformity here.
@formgeist should we follow the ordering of APM for this change, and then create a new issue to switch the buttons across Observability apps? Alternatively we can just keep settings in the front.
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 just pushed 452d11f which switches the settings and alerts options.
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.
@formgeist should we follow the ordering of APM for this change, and then create a new issue to switch the buttons across Observability apps? Alternatively we can just keep settings in the front.
We have separate issues that address this for the other Observability apps.
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.
@formgeist so you want me to revert the change and have Alerts before Settings?
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.
@justinkambic Sorry, I didn't make that clear. Settings will go in front of alerts like the design suggested.
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.
Ok, sounds like it's configured the way we want then.
…sting `button`s within `buttons`.
This was a great find and it's caused by a misuse of the API for |
Thanks all for feedback, I think it's all been addressed so far. |
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.
My feedback is addressed !!
💚 Build SucceededMetrics [docs]Module Count
Async chunks
Unknown metric groupsReferences to deprecated APIs
History
To update your PR or re-run it, just comment with: |
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. I created #100725 as I noticed some potential focus issues related to this but broader than this PR.
* Move uptime actions to Kibana's HeaderActionsMenu. * Delete a comment. * Extract ActionMenu content to dedicated component to make testing easier. * Add tests. * Use `EuiHeaderLinks` instead of `EuiFlexItem`. * Clean up tests. * Prefer `getByRole` for a test. * Fix copy mistake. * Fix a test broken by the previous commit. * Prefer `EuiHeaderSectionItem` over `EuiHeaderSectionLink` to avoid nesting `button`s within `buttons`. * Reverse "Settings" and "Alerts" menu options to make them uniform with APM. Co-authored-by: Kibana Machine <[email protected]>
💚 Backport successful
This backport PR will be merged automatically after passing CI. |
* Move uptime actions to Kibana's HeaderActionsMenu. * Delete a comment. * Extract ActionMenu content to dedicated component to make testing easier. * Add tests. * Use `EuiHeaderLinks` instead of `EuiFlexItem`. * Clean up tests. * Prefer `getByRole` for a test. * Fix copy mistake. * Fix a test broken by the previous commit. * Prefer `EuiHeaderSectionItem` over `EuiHeaderSectionLink` to avoid nesting `button`s within `buttons`. * Reverse "Settings" and "Alerts" menu options to make them uniform with APM. Co-authored-by: Kibana Machine <[email protected]> Co-authored-by: Justin Kambic <[email protected]>
Summary
Resolves #89556.
Moves the header actions from the uptime app content into the stacked actions header provided by Kibana.
Before
After
Author checklist
Telemetry has been added where relevantI did make changes to the app that make the Overview page image out of date in the docs. Should I create a replacement image?
[ ] Any special/edge cases that need to be manually tested must be documentedReviewer checklist