-
Notifications
You must be signed in to change notification settings - Fork 616
NavList API #2027
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
NavList API #2027
Conversation
|
size-limit report 📦
|
<NavList> | ||
<NavList.Item href="/branches">Branches</NavList.Item> | ||
<NavList.Item href="/tags">Tags</NavList.Item> | ||
<NavList.Item> |
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.
(weakly held opinions) Let's talk subnav,
1.1 Making sub item work: Should we give this expandable item a special name?
like NavList.CollapsableItem
, NavList.ExpandableItem
, NavList.Section
, NavList.Accordion
, NavList.Details
<NavList>
<NavList.Item href="/branches">Branches</NavList.Item>
<NavList.Item href="/tags">Tags</NavList.Item>
<NavList.ExpandableItem>
Actions
<NavList.LeadingVisual></ActionIcon/></NavList.LeadingVisual>
<NavList.SubItem href="/actions">General</NavList.SubItem>
<NavList.SubItem href="/actions/runners">Runners</NavList.SubItem>
</NavList.ExpandableItem />
</NavList>
➕ explicit over implicit leads to more predictable API / readable application code?
➖ subItems and item text/visual as siblings feels off
➖ verbose name
1.2 Making sub item work: Should we give this expandable item a special prop instead?
like <NavList.Item expandable>
<NavList>
<NavList.Item href="/branches">Branches</NavList.Item>
<NavList.Item href="/tags">Tags</NavList.Item>
<NavList.Item expandable>
Actions
<NavList.LeadingVisual></ActionIcon/></NavList.LeadingVisual>
<NavList.SubItem href="/actions">General</NavList.SubItem>
<NavList.SubItem href="/actions/runners">Runners</NavList.SubItem>
</NavList.Item/>
</NavList>
➕ explicit over implicit leads to more predictable API / readable application code?
➕ minimal API
➖ the extra prop doesn't really do anything other than make the intent clear
➖ subItems and item text/visual as siblings feels off
2. Forget SubItem
, wrap items in NavList.SubNav
<NavList>
<NavList.Item href="/branches">Branches</NavList.Item>
<NavList.Item href="/tags">Tags</NavList.Item>
<NavList.Item>
Actions
<NavList.LeadingVisual></ActionIcon/></NavList.LeadingVisual>
<NavList.SubNav>
<NavList.Item href="/actions">General</NavList.Item>
<NavList.Item href="/actions/runners">Runners</NavList.Item>
</NavList.SubNav>
</NavList.Item/>
</NavList>
➕ items wrapped in SubNav
feels slightly better than direct siblings to item text/visual
➕ the same NavList.Item
which accepts the same props*
➕ explicit over implicit leads to more predictable API / readable application code?
➖ verbose API
➖ does not match view-components API
Proir art: auth0/cosmos; API | Visual
/* assuming that's good, and subitem does not need to restricted to just text
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.
Looking at other primer implementations for inspiration,
- primer/css uses
.ActionList-item .ActionList-item--hasSubItem
- primer/view-components seems to infers it from children
As the view-components implementation is marked as experimental, I think it's okay to diverge from it at this point if we can find an API that works for both
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 the view-components implementation is marked as experimental, I think it's okay to diverge from it at this point if we can find an API that works for both
Agree!
Making sub item work: Should we give this expandable item a special name?
Initially I kept Item
as generic in PCSS, but eventually ended up creating ItemCollapsible
as a separate entity. It felt easier to work with as its own component, but I don't have a strong preference over any of the options @siddharthkp listed above 😄
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 amazing feedback. Thank you @siddharthkp! I've scheduled some time to discuss the nuances of these API options. Feel free to move the calendar event if another time is more convenient :)
Another API consideration: TreeView/TreeGrid will need to support similar expand/collapse functionality. I would love to pick an API that we can use across all three components
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.
/* assuming that's good, and subitem does not need to restricted to just text
Good question! @vdepizzol @langermank Should subitem support all the same functionality as item or is it more restrictive?
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.
@siddharthkp and I tentatively decided to move forward with option 2:
<NavList>
<NavList.Item href="/branches">Branches</NavList.Item>
<NavList.Item href="/tags">Tags</NavList.Item>
<NavList.Item>
Actions
<NavList.LeadingVisual></ActionIcon/></NavList.LeadingVisual>
<NavList.SubNav>
<NavList.Item href="/actions">General</NavList.Item>
<NavList.Item href="/actions/runners">Runners</NavList.Item>
</NavList.SubNav>
</NavList.Item/>
</NavList>
If anyone has strong opinions against this API, please let me know
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 @siddharthkp mentioned, the PVC NavigationList
infers whether or not it should expand/collapse by determining if it has any sub-items, i.e. any item that has sub-items can be expanded/collapsed. That seemed like a reasonable assumption at the time. Will there ever be a need for a list of non-collapsible sub-items?
The API you've chosen makes sense, but I do wonder if simply using <NavList.SubItem ...>
would be closer to the PVC API. For example:
<NavList>
<NavList.Item href="/branches">
Branches
<NavList.SubItem href="/actions">General</NavList.SubItem>
<NavList.SubItem href="/actions/runners">Runners</NavList.SubItem>
</NavList.Item/>
</NavList>
My understanding is navigation lists only ever have one nesting level.
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 understanding is navigation lists only ever have one nesting level.
I think you're correct. We're working on a TreeView
component to support more levels of nesting.
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 do wonder if simply using <NavList.SubItem ...> would be closer to the PVC API
@siddharthkp and I are leaning towards the <NavList.SubNav>
component because it will allow us to create a predictable and consistent API across NavList
, TreeView
, and TreeGrid
. Would a similar API work for ViewComponents?
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.
@colebemis yeah that works for me 😄 Just as long as it's not expected that SubNav
s are a whole nav unto themselves, i.e. can themselves have sub navs, etc.
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.
Looking good!
<NavList> | ||
<NavList.Item href="/branches">Branches</NavList.Item> | ||
<NavList.Item href="/tags">Tags</NavList.Item> | ||
<NavList.Item> |
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 the view-components implementation is marked as experimental, I think it's okay to diverge from it at this point if we can find an API that works for both
Agree!
Making sub item work: Should we give this expandable item a special name?
Initially I kept Item
as generic in PCSS, but eventually ended up creating ItemCollapsible
as a separate entity. It felt easier to work with as its own component, but I don't have a strong preference over any of the options @siddharthkp listed above 😄
<li><a href="/">Dashboard</a></li> | ||
<li><a href="/pulls">Pull requests</a></li> | ||
<li><a href="/issues">Issues</a></li> | ||
<div role="separator"></div> |
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 think you need aria-hidden="true"
here as well
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'm curious what purpose role
would serve if aria-hidden
is set to true
cc @ichelsea
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.
Good question, I think I added that based on the a11y audit but didn't research it myself.
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.
cc: @alliethu I'm not entirely sure the nuances on this one
|
||
```jsx | ||
<NavList> | ||
<NavList.Group title="Overview"> |
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 assume groups in NavList
are analogous to the concept of sections in NavigationList
? If so, why not call them sections in NavList
as well?
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 called it Group
because that what it's called inActionList
: https://primer.style/react/ActionList#with-groups
It looks like "section" and "group" are used interchangeably in some of our docs. I propose that we standardize on "group" in Primer React and ViewComponents because it aligns with the ARIA role (group). Here's some more context
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 good to me, just left a few non-blocking comments. One remaining question: why is the component called NavList
instead of NavigationList
?
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.
<details> | ||
<summary>Rendered HTML</summary> |
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.
Is the <details>
and <summary>
content meant to be inside the html
codefence?
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.
No. These were a temporary way to get review on the rendered HTML without cluttering the document too much. I'll remove these <details>
sections when I implement the component.
|
||
```html | ||
<nav> | ||
<ul role="list"> |
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.
Do we need to render role="list"
if we're using a <ul>
?
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.
Yes @colebemis! That's correct 🙂 . It's a failsafe for the browsers that remove it.
@camertron we had a conversation about "NavigationList" vs "NavList" in Slack. The consensus was to rename NavigationList to NavList in both React and ViewComponents to save characters and align with UnderlineNav and the |
In the spirit of documentation-driven development (DDD), I've drafted the documentation for the
NavList
(previouslyNavigationList
) component. I'm looking for feedback on the component API before I begin implementation.✨ Direct link to the docs preview
Code review notes
NavigationList
toNavList
to save characters and align withUnderlineNav
and the<nav>
element (Slack discussion). TheNavigationList
ViewComponent will be renamed toNavList
when it's moved from dotcom into the primer/view_components repo.title
be a required prop on theNavList.Group
component?Part of https://github.com/github/primer/issues/637