New Navigation Layout (Sidebar)

[calebjacob]

Closes: #1051

• Implement new sidebar navigation layout when user is signed in
• Show existing navigation layout when user is not signed in. The previous navigation has been renamed to <NavigationSignedOut />.
• Implement mobile designs
• Created unified and simplified wrapping container for all BOS components via <RootContentContainer />. This was required due to our new sidebar layout taking up horizontal screen space.
• Moved the <CookiePrompt /> to its own component and applied wrapping styles to make sure it doesn't impact the layout.
• Render BOS components in signed in header (search, profile dropdown, notification dropdown). Related to: BOS UI search bar, notifications, and profile icon component(s) #1050

The change to using <RootContentContainer /> will also give component authors more control:

1. They can create components that fill up the entire screen space without being limited by max-width or padding that they couldn't control before.
2. They can also vertically and horizontally align a component's contents in the available space via flex-grow or margin: auto.
3. It's up the author to decide what padding and/or max-width makes sense for their component/application.

Important Notes:

• Due to loading the wallet state asynchronously on the client after the page has loaded, there will be a flicker where the layout briefly shows the signed out layout while that logic resolves. Once it does resolve and the user is signed in, we switch to the signed in layout. This isn't ideal UX - we'll need to think through solutions for this.
• Some BOS components now have overflow issues due to the new layout taking up more horizontal space. Updates to these BOS components will need to be deployed separately to resolve this.
• We'll keep this PR open to preview the new layout until we feel like it's ready for production. This could take another sprint or two based on feedback and testing.

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Comments	Updated (UTC)
near-discovery	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Mar 21, 2024 4:42pm
near-discovery-testnet	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Mar 21, 2024 4:42pm

[charleslavon]

@vanessadespain should we have an icon here to give users another discoverable path to collapse this layered menu?

[charleslavon]

@vanessadespain I'm wondering if it would be helpful to have a more noticeable state change when one hovers over a menu option.

The 1st layer menu has a tool tip that pops up on hover and the icons become bold. Perhaps that's sufficient there. The 2nd layer menu has the same bold effect, but it seems really subdued to me. Should we consider adding a border radius around hovered items, or some other effect?

[charleslavon]

hey @calebjacob, this is probably still wip but just to share that when on the mobile view, clicking on a menu option does not close the menu to reveal the selected content.

[vanessadespain]

@charleslavon Totally agree on more clear hover states! I'll pick this up next sprint as well as thinking through how we could collapse/uncollapse the layered menu.

[calebjacob]

Thanks for the great feedback! And thanks for pointing out that issue for our small screen nav @charleslavon - hadn't fully battle tested the mobile nav yet. I just pushed changes that should iron things out. Also got the hover states updated to be a bit more obvious thanks to @vanessadespain.

[charleslavon]

Nice! LGTM 🔥

[calebjacob]

Hey @charleslavon @shelegdmitriy @vanessadespain, I just pushed an update that now includes the BOS components @shelegdmitriy built for the header area (search, notification dropdown, profile dropdown). Please feel free to test out the preview build.

I'd consider this PR now functionally complete. It's just a matter of deciding when we're ready for these changes to make it to production.

[calebjacob]

Hey @charleslavon, I'm realizing this PR has a few changes that would be really nice to have deployed to production. Mainly the changes to RootContentContainer and CookiePrompt.

This got me thinking that it probably makes sense to tie our new sidebar layout to an environment variable (feature flag). We'd leave it disabled for now so that we could merge this PR now while still rendering our existing navigation until we're ready to break things out like we've been talking about.

This would make our BOS component container refactor easier and prevent more merge conflicts as well. What do you think?

[shelegdmitriy]

Great job!

[calebjacob]

@charleslavon @shelegdmitriy I just pushed some changes that should allow us to merge this PR now:

• The new sidebar layout is now hidden behind a feature flag NEXT_PUBLIC_SIDEBAR_LAYOUT=true. This env variable has NOT been enabled in Vercel. We'll keep this variable unset/disabled in Vercel until we're ready to split out the gateway and marketing websites.
• Visit any URL with ?sidebar=true to temporarily enable the sidebar layout while we're still testing it out. If you refresh the page or open a new tab, you'll revert back to the marketing layout.
• Renamed navigation components to make their intent clearer: SidebarNavigation and MarketingNavigation
• Both layouts now fully handle signed in and signed out states (added our existing Sign In and Create Account buttons to the sidebar layout).
• No more layout flickering! The layout is entirely based on the new feature flag and doesn't need to wait on resolving the user's signed in state.

One important note on merging this PR: I'm going to wait to merge this until I have another PR up and ready on the components repo to adjust our pages to using the .gateway-page-container class.