v5 new component: MobileNavItem

[ss-dimasm]

Abstract

To create the MobileNavMenu component (a part of the AppBar), we need to define a scope that focuses on the smaller, individual MobileNavItem components that will be contained within it

This component is responsible for:

1. Displaying the single basic item variant
2. Displaying the collapsed expandable item variant
3. Displaying the expanded expandable item variant

Specification

• Is new component or existing? new
• Is the component design signed off by product and design? Signed off as part of the AppBar changes
• Guide to component structure & documentation in storybook
• Link to DS in Figma
• Accessibility requirements

Developer Checklist

• [ ] Styles alignment between Design System and Elements
• [ ] Check design tokens in Figma and implement CSS variable tokens if available for relevant component
• [ ] Align with accessibility standards / spec as per above
• [ ] If relevant, break down component into Styles Only and React component structures
• [ ] Ensure all variants of components are documented as appropriate
• [ ] Ensure unit test coverage is adequate for component
• [ ] Update documentation in MDX file as per guidelines
• [ ] Changelog updated to reflect a single beta version per component ideally

Release Checklist

• [ ] Approved PR merged to main
• [ ] Design & product review and feedback addressed by developer
• [ ] Beta release by product / engineering lead to next beta version

Additional Context or Information

[ss-dimasm]

Hi @kurtdoherty and @adrian-reapit FYI , I raise this issue to ensure we're aligned on how the future Mobile Navigation Menu will be scaffolded. This ticket covers an item that would act as a "primary menu" "secondary menu" and "user menu" in the future

We've done a bare-minimum proof-of-concept that allows us a basic reference before implementing it in the actual code https://codesandbox.io/p/devbox/mystifying-darkness-sm68c4

question: shall we start to add the keyboard interaction to the MobileNavItem component? or is it more feasible to attach it to the MobileNavMenu component, which is the parent of the MobileNavItem collections

[ss-dimasm]

We've done a bare-minimum proof-of-concept that allows us a basic reference before implementing it in the actual code

thought: with the current POC, I think we could have the improvement such like defining the proper API and change some structures to follow the Disclosure Pattern

Any input is welcome before we start adding this component

[kurtdoherty]

This ticket covers an item that would act as a "primary menu" "secondary menu" and "user menu" in the future

I don't understand what you mean by "primary menu", "secondary menu" and "user menu". Can you please explain what these are?

question: shall we start to add the keyboard interaction to the MobileNavItem component? or is it more feasible to attach it to the MobileNavMenu component, which is the parent of the MobileNavItem collections

Good question. I'm not 100% sure where the behaviour should live 🤔 Without having thought about it much, it feels reasonable for an item to handle navigating "into" its child items if and only if it is expanded (as well as the expand/collapse key handling); otherwise, it could do nothing and allow the menu to handle the key press such that it focuses the next top-level item?

thought: ...follow the Disclosure Pattern

Hmm, seems there's two disclosure patterns being talked about in Teams. I've been referring to this one: https://www.w3.org/WAI/ARIA/apg/patterns/disclosure/examples/disclosure-navigation/, but you've linked https://www.w3.org/WAI/ARIA/apg/patterns/disclosure/examples/disclosure-navigation-hybrid/. May need to do a diff of the two so we understand the differences. My assumption is the hybrid is more complex, but maybe not.

[ss-dimasm]

I don't understand what you mean by "primary menu", "secondary menu" and "user menu". Can you please explain what these are?

I took that references from the design... the mobile navigation menu is actually an AppBar but with a new looks

• black = primary navigation menu
• yellow = secondary navigation menu
• red = user menu

it feels reasonable for an item to handle navigating "into" its child items if and only if it is expanded ... and allow the menu to handle the key press such that it focuses the next top-level item

Yes, I think we need more thoughts on this. In my previous assumption, it might work if these items reside within the parent of collections, enabling a centralized controller. Sub-level item navigation could also be managed from there 🤔

My assumption is the hybrid is more complex, but maybe not.

Regardless of complexity, I think the disclosure-navigation pattern aligns more closely with the current design specification

[kurtdoherty]

I took that references from the design... the mobile navigation menu is actually an AppBar but with a new looks

Ahh, right, yes the mobile nav menu includes items that mirror the items in the primary nav, secondary nav and user profile menu on larger screens 👍

Regarding where the keyboard nav logic should go, it may just be something we need to see in code 🤷‍♂️

[ss-dimasm]

Regarding where the keyboard nav logic should go, it may just be something we need to see in code

can I assume that statement is a signal for us to start shipping the component? 👀

[kurtdoherty]

Yep, though it may be good to summarise the component interface you're aiming for in this ticket. I've found in the past that what is shown in POCs isn't always what engineers submit for review 😛

Given the time of day for me though, you don't need to wait for approval on the interface before starting work 👍