refactor: update the navbar to match the new designs #15964

BrunoQuaresma · 2024-12-27T15:11:23Z

Update the navbar to match the designs in this Figma file. Related to #15617.

Desktop preview:

Screen.Recording.2024-12-27.at.12.13.38.mov

Mobile preview:

Screen.Recording.2024-12-27.at.12.12.42.mov

For a closer look, you can check Chromatic snapshots or test the changes locally.

A few considerations:

I made some adjustments to improve the design, such as removing the chevron from the profile menu and reducing the size of the chevrons in the dropdowns. I’ve documented these changes in the Figma file so @chrifro can review them after returning from vacation.
Some of the design questions involve how the proxy and account dropdown menus should look on desktop and mobile. For desktop, I decided to retain the current styles, and for mobile, I tried to infer how they should look based on the existing design.
There is some duplicated logic between the regular/desktop navbar menus and the mobile menus, which could lead to inconsistencies and make maintenance harder in the future. I plan to address this in a follow-up PR to keep this review manageable.
I’ve added tests to minimize inconsistencies and potential bugs while working on this refactor.

…-navbar

Parkreiner

Looks good so far!
Close to approving this – I left a few comments, but nothing blocking. I just want to take the UI for a test drive to make sure I didn't miss anything

Parkreiner · 2024-12-27T15:54:17Z

site/src/index.css

@@ -70,4 +70,10 @@
 	* {
 		@apply border-border;
 	}
+
+	/** Related to https://github.com/radix-ui/primitives/issues/3251 */


Could the comment also be updated to list what components rely on this patch?

Parkreiner · 2024-12-27T16:01:46Z

site/src/components/Button/Button.tsx

-		/>
-	);
-});
+export const Button = forwardRef<HTMLButtonElement, ButtonProps>(


I'm just now realizing: do we want the ref type to always be HTMLButtonElement? I'm thinking about cases like this:

<Button asChild> <a href="#">Not actually a button in the output</a> </Button>

Where TypeScript will think it's a button, but the actual HTML node will be for an anchor. I'm not sure what properties are on one but not the other, but calling a button method that doesn't exist could blow up the app

Only thing is, I'm not actually sure how you would add a generic ref type to forwardRef, since it's just a function call, and not a full function signature

I don't think this is worth blocking over, but I'll try to figure out a fix next week

I think your concern is totally valid, but this is the default implementation from the shadcn/ui Button. I’d be open to changing it only if necessary, as I’d prefer not to add complexity without bringing justifiable value to us.

Parkreiner · 2024-12-27T16:04:54Z

site/src/components/Button/Button.tsx

+		);
+	},
+);
+Button.displayName = "Button";


I know there were some conversations about getting rid of displayName, but we weren't sure if it was necessary for forwarded anonymous components. Does the component not get a name in the dev tools if the name isn't set here?

Ah, okay, I wasn’t aware of that. Thanks for letting me know! I’ve just been copying and pasting the default implementation and making changes only when necessary.

Parkreiner · 2024-12-27T16:10:55Z

site/src/modules/dashboard/Navbar/proxyUtils.tsx

+	proxies: Proxies,
+	latencies: ProxyLatencies,
+) {
+	return [...proxies].sort((a, b) => {


Could we get away with replacing this with a call to .toSorted?

TIL https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Array/toSorted

Parkreiner · 2024-12-27T16:16:00Z

site/src/modules/dashboard/Navbar/UserDropdown/UserDropdown.tsx

-							close={open}
-						/>
-					</div>
+				<button


Is there a reason why we're still using the default HTML button here, instead of adding a new variant to the Button component?

This button style isn’t used anywhere else, so I’d avoid creating a new variant (essentially an abstraction) for just a single use case. If we encounter more use cases like this in the future, I think that would be the right time to turn it into a variant.

Parkreiner · 2024-12-27T16:42:13Z

site/src/modules/dashboard/Navbar/Navbar.test.tsx

@@ -26,7 +25,7 @@ describe("Navbar", () => {
 		await userEvent.click(deploymentMenu);
 		await waitFor(
 			() => {
-				const link = screen.getByText(Language.audit);
+				const link = screen.getByText("Audit Logs");
 				expect(link).toBeDefined();


Is this check needed since getByText will throw if a node can't be found?

You’re right, it’s not needed.

Parkreiner · 2024-12-27T16:45:43Z

site/src/modules/dashboard/Navbar/Navbar.test.tsx

@@ -26,7 +25,7 @@ describe("Navbar", () => {
 		await userEvent.click(deploymentMenu);
 		await waitFor(
 			() => {
-				const link = screen.getByText(Language.audit);
+				const link = screen.getByText("Audit Logs");


Could we update these to be role selectors, too?

Parkreiner · 2024-12-27T16:49:42Z

site/src/modules/dashboard/Navbar/MobileMenu.tsx

+	open: "text-content-primary",
+};
+
+type MobileMenuProps = MobileMenuPermissions & {


Nit: could this be moved below MobileMenuPermissions? When I was reading this top to bottom, I had to do a double take to see where the permissions were defined

Parkreiner · 2024-12-27T16:55:14Z

site/src/components/DropdownMenu/DropdownMenu.tsx

+export interface DropdownMenuButtonProps
+	extends ComponentPropsWithoutRef<typeof Button> {}
+
+export const DropdownMenuButton = forwardRef<


I'm wondering if it's a little confusing to have a file export both a trigger and a button, especially since the button doesn't use the trigger internally

Hm... I hadn’t thought of that 🤔. Honestly—maybe it’s just personal—I don’t see any confusion since a trigger is a behavioral component and a button is a visual component. To me, it feels okay to have both. What would you suggest?

@BrunoQuaresma It looks like you are adding DropdownMenuButton to the shadcn DropdownMenu component? Im curious why it is necessary to add this?

The purpose of this component is to make dropdown button styling consistent. For example, instead of composing a Button + Icon + styling in every component or page where you want to add a dropdown, you could use a consistent component to reduce boilerplate. While I don’t mind boilerplate in general, in this case, since we already have a consistent design, it could help avoid inconsistencies.

Before:

<Button ref={ref} variant="outline"> Admin settings <DropdownMenuChevronDown /> </Button>

After:

<DropdownMenuButton>Admin settings</DropdownMenuButton>

However, while writing this, I thought of another approach that might be better—creating a new dropdown variant in the Button component:

<Button ref={ref} variant="dropdown"> Admin settings </Button>

Thoughts?

If every DropdownMenu component will always use the DropdownMenuButton with this styling then it could make sense. However. that may not always be the case. I personally like having a dropdown variant for the button component more than altering the DropdownMenu component.

I decided to remove the DropdownMenuButton component for now until we actually need it.

Parkreiner · 2024-12-27T17:00:35Z

site/src/modules/dashboard/Navbar/MobileMenu.tsx

+					}}
+				>
+					Workspace proxy settings:
+					<span className="leading-[0px] flex items-center gap-1">


I don't think we want to set the line height to 0. It'll cause a lot of text rendering issues the moment the text has to wrap around

99% sure we want to set this to leading-none to set the text solid (line height of 1)

Noted! I’m not sure why, but when I used a line height of 1, it was misaligned, and I only managed to fix it by setting it to 0. I’ll double-check that.

Parkreiner

Quick notes from testing things out:

Do we want to add overflow-x: auto to NavItems? That way if the viewport shrinks enough on mobile, the user can still scroll to the page link that they want
I also feel like the new navbar feels a little off with the rest of the site. The navbar and the sub-navigation below it are just different enough to be noticeable, while still similar enough to make it feel like it wasn't intentional

I posted a comment on the Figma design, but I really can't help but feel like the blurred background is a mistake. The comment goes into more detail, but I think a solid background is way less disorienting

Screen.Recording.2024-12-27.at.12.37.22.PM.mov

Still, I'm going to approve. We can always update the design in a second pass once Christin is back

BrunoQuaresma · 2024-12-27T18:00:34Z

Do we want to add overflow-x: auto to NavItems? That way if the viewport shrinks enough on mobile, the user can still scroll to the page link that they want

I don’t think so—or at least, I wouldn’t expect that. What viewport did you use? If it’s something under 360px, I think we can safely skip it since that’s not very common these days.

Reference: Common Screen Resolutions

I also feel like the new navbar feels a little off with the rest of the site. The navbar and the sub-navigation below it are just different enough to be noticeable, while still similar enough to make it feel like it wasn't intentional

Good catch, I’ll fix that 👍.

I posted a comment on the Figma design, but I really can't help but feel like the blurred background is a mistake. The comment goes into more detail, but I think a solid background is way less disorienting

Ahhh, you’re right. I definitely prefer the solid background over the blurry one, but let’s let @chrifro make the final decision on it.

cc.: @Parkreiner

BrunoQuaresma added 11 commits December 26, 2024 15:33

Refactor navbar on desktop

3900600

Remove unecessary imports and fix skeleton height

916c0a7

Add basic structure for mobile menu

8837484

Merge branch 'main' of https://github.com/coder/coder into bq/improve…

f365421

…-navbar

Finish mobile menu

072a6d8

Merge branch 'main' of https://github.com/coder/coder into bq/improve…

a040a3b

…-navbar

Add icon sizes

2a79316

Adjust icon sizes

1b0c075

Extract MobileMenu

7956d56

Add stories for mobile menu

7f9a95d

Fix fmt and lint

7e11d46

BrunoQuaresma self-assigned this Dec 27, 2024

BrunoQuaresma requested review from a team, code-asher, jaaydenh and Parkreiner and removed request for a team and code-asher December 27, 2024 15:11

Parkreiner reviewed Dec 27, 2024

View reviewed changes

Parkreiner approved these changes Dec 27, 2024

View reviewed changes

BrunoQuaresma requested a review from Parkreiner December 30, 2024 13:08

BrunoQuaresma added 4 commits December 30, 2024 13:20

Apply PR review suggestions

07ce677

Align breadcrumb, deployment and org settings layouts to navbar.

0699cb4

Remove DropdownMenuComponent

2830801

Run make fmt

08f92e5

BrunoQuaresma merged commit 49fadb8 into main Dec 30, 2024
29 checks passed

BrunoQuaresma deleted the bq/improve-navbar branch December 30, 2024 17:25

github-actions bot locked and limited conversation to collaborators Dec 30, 2024

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

refactor: update the navbar to match the new designs #15964

refactor: update the navbar to match the new designs #15964

BrunoQuaresma commented Dec 27, 2024 •

edited

Loading

Parkreiner left a comment •

edited

Loading

Parkreiner Dec 27, 2024

Parkreiner Dec 27, 2024

Parkreiner Dec 27, 2024

BrunoQuaresma Dec 27, 2024

Parkreiner Dec 27, 2024

BrunoQuaresma Dec 27, 2024

Parkreiner Dec 27, 2024

BrunoQuaresma Dec 27, 2024

Parkreiner Dec 27, 2024

BrunoQuaresma Dec 27, 2024

Parkreiner Dec 27, 2024

BrunoQuaresma Dec 27, 2024

Parkreiner Dec 27, 2024

Parkreiner Dec 27, 2024

Parkreiner Dec 27, 2024

BrunoQuaresma Dec 27, 2024

jaaydenh Dec 28, 2024

BrunoQuaresma Dec 30, 2024

jaaydenh Dec 30, 2024

BrunoQuaresma Dec 30, 2024

Parkreiner Dec 27, 2024

BrunoQuaresma Dec 27, 2024

Parkreiner left a comment

BrunoQuaresma commented Dec 27, 2024 •

edited

Loading

refactor: update the navbar to match the new designs #15964

refactor: update the navbar to match the new designs #15964

Conversation

BrunoQuaresma commented Dec 27, 2024 • edited Loading

Parkreiner left a comment • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Parkreiner left a comment

Choose a reason for hiding this comment

BrunoQuaresma commented Dec 27, 2024 • edited Loading

BrunoQuaresma commented Dec 27, 2024 •

edited

Loading

Parkreiner left a comment •

edited

Loading

BrunoQuaresma commented Dec 27, 2024 •

edited

Loading