What is being proposed?
Two new components, built on top of the existing SidebarNav:
SecondaryNav: a second, contextual navigation panel (grouped items, optional one-level nesting, optional search, optional title/back header) that sits alongside the primary sidebar. It renders as a fixed side panel on desktop and a temporary overlay drawer on mobile.
NavigationLayout: a composing layout component that owns SidebarNav + SecondaryNav + main content together, and handles the responsive coordination between the two panels (e.g. only one temporary drawer visible at a time on mobile, back-navigation between them).
Why is this needed?
SidebarNav alone only models a single, flat/nested primary navigation tree. Several Diamond apps need a second level of navigation that's contextual to what's selected in the primary sidebar (e.g. picking Experiments in the sidebar, then navigating between each experiment in a secondary panel), something like SidebarNav's pattern, but for a scoped set of items that changes with context.
Without a shared component, each consuming app would re-implement this panel-plus-drawer pattern, including the fiddly responsive behaviour (mobile drawer stacking, back button wiring, history/popstate handling)
that NavigationLayout centralises.
What will change?
- Introduces two new components:
SecondaryNav and NavigationLayout (both already implemented and exported from src/index.ts on this branch).
- No changes to existing component props/behaviour, other than a small addition to
SidebarNav (see below) needed for NavigationLayout to drive it.
- New shared type:
LinkProps in src/components/navigation/types.ts, reused by SecondaryNav's item definitions.
Interface changes (if any)
// Standalone SecondaryNav
<SecondaryNav
open={open}
setOpen={setOpen}
title="Beamline I03"
search={{ value, onChange, placeholder: "Search" }}
groups={[
{
subheader: "Experiments",
items: [
{ id: "exp-1", label: "Experiment 1", linkProps: { href: "/exp-1" }, selected: true },
{
id: "exp-2",
label: "Experiment 2",
children: [
{ id: "exp-2-a", label: "Run A", linkProps: { href: "/exp-2/a" } },
],
},
],
},
]}
/>
// Composed with SidebarNav via NavigationLayout
<NavigationLayout
navigation={navigation}
sidebarOpen={sidebarOpen}
setSidebarOpen={setSidebarOpen}
secondaryNav={{ title: "Beamline I03", groups }}
secondaryNavOpen={secondaryNavOpen}
setSecondaryNavOpen={setSecondaryNavOpen}
>
{children}
</NavigationLayout>
Breaking change?
Next steps
A maintainer will review this issue.
If accepted, it will be marked as accepted and a PR may then be opened.
What is being proposed?
Two new components, built on top of the existing
SidebarNav:SecondaryNav: a second, contextual navigation panel (grouped items, optional one-level nesting, optional search, optional title/back header) that sits alongside the primary sidebar. It renders as a fixed side panel on desktop and a temporary overlay drawer on mobile.NavigationLayout: a composing layout component that ownsSidebarNav+SecondaryNav+ main content together, and handles the responsive coordination between the two panels (e.g. only one temporary drawer visible at a time on mobile, back-navigation between them).Why is this needed?
SidebarNavalone only models a single, flat/nested primary navigation tree. Several Diamond apps need a second level of navigation that's contextual to what's selected in the primary sidebar (e.g. picking Experiments in the sidebar, then navigating between each experiment in a secondary panel), something likeSidebarNav's pattern, but for a scoped set of items that changes with context.Without a shared component, each consuming app would re-implement this panel-plus-drawer pattern, including the fiddly responsive behaviour (mobile drawer stacking, back button wiring, history/popstate handling)
that
NavigationLayoutcentralises.What will change?
SecondaryNavandNavigationLayout(both already implemented and exported fromsrc/index.tson this branch).SidebarNav(see below) needed forNavigationLayoutto drive it.LinkPropsinsrc/components/navigation/types.ts, reused bySecondaryNav's item definitions.Interface changes (if any)
Breaking change?
Next steps
A maintainer will review this issue.
If accepted, it will be marked as
acceptedand a PR may then be opened.