-
-
Notifications
You must be signed in to change notification settings - Fork 4.3k
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
[EPIC] Stacked Navigation: Milestone 1 (navigation components) #84018
Comments
This was referenced Jan 28, 2025
malwilley
added a commit
that referenced
this issue
Jan 28, 2025
…84129) Ref #84018 I wanted to add navigation components that would show up on both issues stream and details, but currently issue details is not a child of the `/issues` route which means I'd have to render it in two places. I moved the issue details routes so that it is a child of the `/issues` `Route`, which was relatively simple. The one thing I'm a bit worried about is that I removed the customer domain logic. I _believe_ this is okay because the `/issues` route has the prop `withOrgPath` which adds the `/organizations/:orgSlug` path as well. Here's an example of this being done before: #66747
andrewshie-sentry
pushed a commit
that referenced
this issue
Jan 29, 2025
…84129) Ref #84018 I wanted to add navigation components that would show up on both issues stream and details, but currently issue details is not a child of the `/issues` route which means I'd have to render it in two places. I moved the issue details routes so that it is a child of the `/issues` `Route`, which was relatively simple. The one thing I'm a bit worried about is that I removed the customer domain logic. I _believe_ this is okay because the `/issues` route has the prop `withOrgPath` which adds the `/organizations/:orgSlug` path as well. Here's an example of this being done before: #66747
c298lee
pushed a commit
that referenced
this issue
Jan 29, 2025
…84129) Ref #84018 I wanted to add navigation components that would show up on both issues stream and details, but currently issue details is not a child of the `/issues` route which means I'd have to render it in two places. I moved the issue details routes so that it is a child of the `/issues` `Route`, which was relatively simple. The one thing I'm a bit worried about is that I removed the customer domain logic. I _believe_ this is okay because the `/issues` route has the prop `withOrgPath` which adds the `/organizations/:orgSlug` path as well. Here's an example of this being done before: #66747
This was referenced Jan 29, 2025
This was referenced Feb 5, 2025
malwilley
added a commit
that referenced
this issue
Feb 11, 2025
Ref #84018 The new nav structure moves `/discover/` to `/explore/discover/`. To facilitate the transition, I'm adding a util `makeDiscoverPathname()` that will check a feature flag to decide which link to generate. In order to use this I needed to change many function arguments from `orgSlug` to `organization`.
This was referenced Feb 11, 2025
This was referenced Feb 20, 2025
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
At present, items in the side nav are defined in a central location by a config object (see code here). These config items are quite rigid, only allowing for a label and a pathname. In order to support issue and other saved views with custom behavior, it would be beneficial to move the rendering of these items into the product areas themselves so that product teams can easily access and share state with the main content.
The system should be flexible enough to support all present feature in issue views (overflow menus, custom selection behavior based on variables other than the URL, drag and drop, etc), as well as future features that we cannot yet anticipate. Each individual product team should be able to render custom components without needing to modify any internal side nav components. In order to keep things looking consistent, there should be a suite of composable components to build the UI from.
Another requirement is that we need this solution to handle a collapsible sidebar. When collapsed (either by user action or because the screen is too small), the sidebar items should instead be rendered in a flyout. When the screen is even smaller, nav items will be rendered in a
Component Design
Proposed Structure
<SecondaryNav />
NavContext
to determine the portal target. TheNavContext
will contain a reference to the element, which may change based on screen size or collapsed state.id: NavId
- A unique identifier, likeissues
. Should match theid
given to the top-levelchildren: ReactNode
- Custom content<SecondaryNav.Body />
children: ReactNode
<SecondaryNav.Footer />
children: ReactNode
<SecondaryNav.BodySection />
title?: ReactNode
children: ReactNode
<SecondaryNav.Item />
isActive?: boolean
- Optionally control the active state of the item, if it is not as simple as a matching URLto: To
children: ReactNode
<SecondaryNav.ItemProjectIcon />
projects: string[]
Example usage
Designs
Task list
The text was updated successfully, but these errors were encountered: