feat: Add expandable-icon-end to collapsible side navigation - #4843
feat: Add expandable-icon-end to collapsible side navigation#4843jkuelz wants to merge 5 commits into
Conversation
Add internal __expandIconPosition ('start' | 'end', default 'start') to
InternalExpandableSection. When 'end', the expand caret is DOM-reordered
to the inline-end (preserving focus order for accessibility) across all
variants; the outside-header caret (container and default-with-actions)
renders as an accessible button. Default 'start' behavior is unchanged
and there is no public API change (internal __-prefixed prop).
Groundwork for the side-navigation icon layout. Note: the navigation
variant now wraps its header text in a span (styled only in the end
layout), a minor DOM change for that side-nav-only variant.
When any nav item has an icon, SideNavigation switches to an icon layout: the expand caret moves to the inline-end, item spacing widens, and rows get a full-width hover background. Consumes the existing withIcons signal and threads the internal __expandIconPosition to the Section and ExpandableLinkGroup expandable headers. Also fixes ExpandableSection's to remove content padding for all variants (previously only , despite other variants having default content padding) and corrects its docs. Adds a colorBackgroundSideNavigationItemIconHover design token.
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #4843 +/- ##
=======================================
Coverage 97.63% 97.63%
=======================================
Files 957 957
Lines 31097 31132 +35
Branches 11434 11461 +27
=======================================
+ Hits 30361 30396 +35
+ Misses 729 689 -40
- Partials 7 47 +40 ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
jkuelz
changed the title
|
The collapsed-state behavior feels a bit inconsistent. When a parent has an icon, its children are not shown in the collapsed state:
When the parent has no icon, the collapsed state shows children instead, but only the children that have icons:
Is this the intended behavior? My concern is that this could lead to confusing UX: two sections can behave differently in the collapsed state depending on whether the parent has an icon. In one case, the collapsed nav shows the parent; in another, it shows a subset of the children. Would it be more intuitive to consistently show only parent items in the collapsed state? We could add a dev warning when a parent has no icon set or document in the guidelines that all parents should have icons. |
| styles.content, | ||
| styles[`content-${baseVariant}`], | ||
| expanded && styles['content-expanded'], | ||
| disableContentPaddings && styles['disable-content-paddings'] |
There was a problem hiding this comment.
disableContentPaddings existed before. Is this a breaking change?
There was a problem hiding this comment.
DisableContentPaddings will still exist. The only part that is changing is that now disableContentPaddings applies to variants besides container. I view this more as a bug fix with a clear resolution rather than a breaking change. It might've only applied to the container variant because we didn't have use cases for the others, or the other variants didn't come with content padding (the previous description said, "default padding is only present for the container variant."). Which might've been true at the time, but is not true anymore.
| expect(onChange).toHaveBeenCalledTimes(1); | ||
| }); | ||
| }); | ||
| }); |
There was a problem hiding this comment.
Should we add a test that ensures the tab order is correct for link groups? When _expandIconPosition="start" it should be previous item -> caret -> link -> next item and when _expandIconPosition="end" it should be previous item -> link -> caret -> next item.
| }); | ||
|
|
||
| test('container variant toggles aria-expanded on click', () => { | ||
| const wrapper = renderInternalExpandableSection({ variant: 'container', __expandIconPosition: 'end' }); |
There was a problem hiding this comment.
There's a bug when opening / closing the section with Enter / Space, it opens and closes immediately. Clicking with the mouse works fine, because propagation is prevented for click events, not Enter / Space. We should fix that and have a test for it.
The focus behaves differently when __expandIconPosition: 'end'. With start, the whole header gets the focus. With end, you can tab onto the title, then on the trigger itself, but the trigger does not show a focus ring.
There was a problem hiding this comment.
We should also add this to the /expandable-section/container-variant.permutations and add integration tests for it.
| lineHeightHeadingXs: '20px', | ||
| fontWeightHeadingXs: '500', | ||
|
|
||
| fontSideNavigationSectionHeaderSize: '14px', |
There was a problem hiding this comment.
Why are we removing this? Can we set the values required for one-theme? Otherwise it'll fall back to vr again.
There was a problem hiding this comment.
The desired is the same as VR (16px/500), which is why we are removing it.
There was a problem hiding this comment.
Can we defined it here explicitly still? We'll have to untangle VR with One Theme at one point and keeping things separate makes it easier for us in the future.
There was a problem hiding this comment.
I can, but when we did VR, we only defined the items that were changed from the base theme. Which helped define the line between them, otherwise you're constantly going between the two to find a diff.
There was a problem hiding this comment.
Non-blocking, but we should strive for making One Theme independent. Dependency on VR will cause issues should VR be deprecated in the distant future.
| // Section groups | ||
| // ========================================================================== | ||
| .section-group { | ||
| @include styles.font-heading-m; |
There was a problem hiding this comment.
Does this change how section groups look? This affects all themes.
There was a problem hiding this comment.
It was redundant because we already use Box h3 variant in the parts.tsx file which would apply these styles by default.
e5d8fca to
48e9996
Compare
2 participants
Description
Adjusts the layout of the collapsible SideNavigation variant based on whether icons are present. When any nav item has an icon, the layout adapts: item spacing widens (separate PR #4831), the expand caret moves to the inline-end, and rows get a full-width hover background. Caret moves to end of the row to not clutter the left side when there are icons present, and hover is added to connect the caret and the text. Added an internal
__expandIconPositionto the ExpandableSection component which is then used in SideNav.Also included:
disableContentPaddings: Now removes content padding for all variants, not just container (other variants also have default content padding); API description corrected accordingly.colorBackgroundSideNavigationItemIconHover-- it is a known issue that the hover token's dark 1T value isn't fully reference-token-themeable (won't track a primary-color change) — proper fix needs an alpha palette derived from primary, which is a larger change.Related links, issue #, if available: n/a
How has this been tested?
Dev pipeline (dev-v3-jkuelz)
Review checklist
The following items are to be evaluated by the author(s) and the reviewer(s).
Correctness
CONTRIBUTING.md.CONTRIBUTING.md.Security
checkSafeUrlfunction.Testing
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.