-
Notifications
You must be signed in to change notification settings - Fork 839
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
[EuiCollapsibleNavBeta] Remove ability for accordion/group titles to contain links #7337
Conversation
@MichaelMarcialis Could use your thoughts here again really quick. I added a "group" sub-component recently because Kibana is doing a mildly hacky thing where the arrow is getting hidden for "always open" accordions, which aren't really accordions at all (they're just groups). With that in mind, should group titles be able to be links since accordion titles can't be links? Technically, they can be since there isn't the same accessibility limitation on them, but I'm not sure how confusing that would be from either a developer experience or user experience POV. |
Is this "always open group" what is being show in the below screenshot? If so, I suppose it wouldn't hurt to allow the group's parent to be linkable, as it doesn't carry the burden of also having to toggle an accordion. That said, I am curious about where this pattern is being used and why it would be necessary. For example, wouldn't using a navigation subheader with links below it generally achieve the same hierarchical presentation without stepping on the styles of the navigation accordions? CCing @ryankeairns as well, in case he has any thoughts on the matter. |
I could be wrong but I think the reason why Kibana is doing it is the link in the accordion is in the current open page - essentially they want the link to always be visible in the sidenav(?). Please correct me if I'm wrong @tsullivan @sebelga |
I don’t foresee a need, in the this new nav, for having titles as links. |
- split out shared props, into main `Item` props - easier to follow combined at point as the `items` array prop - have the accordion, group, and link components use `Pick` instead of `Omit` (see above about divergence) NOTE: I played around with an ExclusiveUnion but I find the TS errors too annoying to understand how to fix - I'd rather degrade gracefully than annoy devs with hard to debug TS errors
- the whole accordion trigger should now toggle the accordion - no separate links
… props to accordion or link components + add missing test for `EuiCollapsibleNavGroup` - I forgot to write this before 😬
- not an a11y concern here, but it's more consistent UX wise + add missed `isCollapsible` spread to button component
- remove `href` links from accordions - update `EuiCollapsibleNavItem edge` case story book more permutations
…or group/accordion' props - means that the `items` prop shouldn't be passed at all if `href` is
95182c7
to
882611b
Compare
Thanks y'all - components have been updated to enforce either a |
@sebelga I probably should have surfaced this more visibly, but I added a specific component for that top-level non-collapsible group. It's usable via Storybook: https://eui.elastic.co/storybook/?path=/story/euicollapsiblenavbeta-group--playground I thought I saw in a screenshare with you at one point that there are sub-items that also are non-collapsible accordions however. Was I off on that? |
That was a temporary state until we fixed the controlled expand/collapse state of accordion (in elastic/kibana#169651). With that said, it is still part of our API to allow an accordion to not be collapsible with the following props (but that's not used for now in any of the project navigations) ...
renderAs: 'accordion',
isCollapsible: false, |
Gotcha, sounds good. So basically it shouldn't affect production IA, which is perfect / means this PR is good to go in terms of Kibana impact. Also FYI that the |
Thanks, @cee-chen. These changes look great. I only noticed two small things in my testing:
|
This is something that would need to be resolved at the underlying For now I've adding a workaround to this issue (specific to this component) in fa15cec, which basically removes the margins and increases the arrow size so there isn't any area where a click doesn't toggle the accordion.
Done! Thanks for catching these UI/UX improvements! ❤️ |
@1Copenut do you mind QA/reviewing this PR for merge sometime this week? 🙏 |
Preview staging links for this PR:
|
💚 Build Succeeded
History
|
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.
This is a good refactor @cee-chen. The work here will help reduce errant links where groups shouldn't have them. I tested in the big three screen readers and ran through the manual QA you recommended.
I have one thought that I'm 99% sure should be a separate issue + PR, so I'll mention it here and open a feature request. When we have an accordion that toggles a group open and closed, we actually have two buttons (text + icon) with one ignored for keyboard navigation. Screen readers still recognize that icon button, so there's two buttons with the same name in SR form control menus. This is true with our accordion too, so I feel it'd be appropriate to make this change a separate PR.
Great call Trevor! |
`v90.0.0`⏩`v90.0.1` This release also contains updates to EuiCollapsibleNavBeta, to support serverless UX (elastic/eui#7337). --- ## [`90.0.1`](https://github.com/elastic/eui/tree/vpatch) **This release is a backport intended for Kibana 8.12.** - `EuiSelectable` now allows configurable text truncation via `listProps.truncationProps` ([#7388](elastic/eui#7388)) - `EuiTextTruncate` now supports a new `calculationDelayMs` prop for working around font loading or layout shifting scenarios ([#7388](elastic/eui#7388))
Summary
closes elastic/kibana#168484
Hover/mouse states:
Focus/keyboard states:
QA
General checklist
and cypress tests- [ ] Updated the Figma library counterpart