-
Notifications
You must be signed in to change notification settings - Fork 30
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
docs: Hide nav and add hamburger to collapse side nav #2386
docs: Hide nav and add hamburger to collapse side nav #2386
Conversation
…1-integrate-triton-to-next-gen-docs
* create header component * accurate header width calculation * ToggleThemeButton into Header * align ToggleThemeButton to the right of the header * make sure nav menu aligns with header * border on the header * Header takes up the whole width * make sure only BaseView.Main scrolls with header on top * move top nav to be inside BaseView.Main * refactor Triton SideDrawer into its own component and created TritonContext * header styling * dont use box as main due to lack of boxShadow * make header responsive in minimal mode * fix eslint * overflow auto on main routed div * ask triton button styling * only rounded top corners of main content * fixed main content not growing * fix BaseView border radius * some layout/styling tweaks * add header to collection pages and make scrollbar inside the content * isolate blending to only content card wrapper * align nav with header * Renamed Header to TopNav * use Box instead of div --------- Co-authored-by: Chris Murray <[email protected]>
Deploying atlantis with
|
Latest commit: |
cbd9b25
|
Status: | ✅ Deploy successful! |
Preview URL: | https://492881e5.atlantis.pages.dev |
Branch Preview URL: | https://job-115212-hide-nav-and-add.atlantis.pages.dev |
@@ -63,7 +66,7 @@ function AnimatedPresenceDisclosure({ | |||
isTitleSelected ? styles.selected : "" | |||
} stickySectionHeader`} | |||
> | |||
<Link to={to ?? "/"} tabIndex={0}> | |||
<Link to={to ?? "/"} tabIndex={0} onClick={toggleMobileMenu}> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
these onClick handlers on Link are responsible for closing mobile menu when a route is clicked on
@@ -0,0 +1,37 @@ | |||
import { Box, Button } from "@jobber/components"; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LeftDrawer is a simpler version of our SideDrawer, until we can get SideDrawer to slide out from different directions
min-width: var(--sideBarWidth); | ||
box-sizing: border-box; | ||
|
||
@media screen and (min-width: 768px) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
--medium-screens-and-up
css variable isn't working properly due to missing post-media plugin. There's also a couple other issues with css import that I spotted along the way. Will get another ticket started to deal with it.
@@ -5,10 +5,14 @@ | |||
--navItemHeight: 40px; | |||
display: flex; | |||
flex-direction: column; | |||
padding: 35px 0 0 0; | |||
height: 100dvh; | |||
height: 100%; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
height of NavMenu in mobile viewport should not be 100dvh since it lives inside the LeftDrawer with header on top
….com:GetJobber/atlantis into JOB-115212-hide-nav-and-add-hamburger-to-collapse-side-nav
overflow-y: hidden; | ||
} | ||
|
||
@keyframes slideIn { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm thinking we should also do a slide out animation so it feels a bit less abrupt on the way out
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Added!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
that looks & feels much better!
packages/site/src/layout/NavMenu.tsx
Outdated
<div className={styles.desktopNavContainer}>{menuContent}</div> | ||
<div className={styles.mobileNavContainer}> | ||
<LeftDrawer | ||
open={isMobileMenuOpen} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I know the LeftDrawer
is not a component we're looking to export and re-use much, even still I'm tempted to not have open
be a prop on it since the only way it uses open
is to return null
, and instead let that decision making happen here at the level where we have it in our template
so we'd just do
{isMobileMenuOpen && <LeftDrawer... />
and the LeftDrawer
doesn't have to worry about a case where it shouldn't show.
I wouldn't call this a blocker though.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Updated!
<> | ||
<div className={styles.overlay} onClick={onClose} /> | ||
<div className={styles.drawer}> | ||
<Box padding="small" direction="row" alignItems="center" gap="small"> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
packages/site/src/layout/TopNav.tsx
Outdated
gap="small" | ||
justifyContent={mediumAndUp ? "" : "space-between"} | ||
> | ||
<div className={styles.mobileNavContainer}> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
hmm we already have the mediumAndUp
out at this level, how about we use!mediumAndUp
as the condition to render the mobile nav stuff instead eg. {!mediumAndUp && <Box ...
that way we can get rid of the mobileNavContainer
div, and since that's the only style in TopNav.module.css
that entire file can go too
then we also have the benefit of our responsive stuff being managed in 1 way rather than split between CSS and JS, plus it's always nice to just not render things we don't want rather than hiding them with CSS when possible
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Didn't see this comment before my reply. In this case, it makes sense to only use mediumAndUp
and get rid of the css file entirely.
width={mediumAndUp ? "grow" : "auto"} | ||
padding={mediumAndUp ? { left: "extravagant" } : {}} | ||
> | ||
<Box width={mediumAndUp ? 200 : "auto"}> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
we have a decent amount of ternaries with mediumAndUp
I'm tempted to suggest breaking it into 2 components, and then instead having it be a simpler conditional of which layout to use... but I'm not sure it's really worth it. I wouldn't say the current setup is hard to understand.
what do you think?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
overall I wanted to use media query and steer away from this sort of pattern, but also wanted to keep using Box instead of divs. Agree breaking into two components will be nicer.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
mkay, if you wanna refactor it that definitely works for me!
again I don't think this is in currently in a state where I find it hard to read or anything, so if sharing 90% of the code with this handful of conditionals is beneficial enough, I don't have any hard objections to leaving it as is.
packages/site/src/layout/NavMenu.tsx
Outdated
<Box> | ||
<Link to="/"> | ||
<div className={styles.navMenuHeaderLogo}> | ||
<Link to="/" onClick={toggleMobileMenu}> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
when does this show up?
I've tried replacing the content with HELLO WORLD and I only ever see it when we're in not-mobile mode, at which point I'd ask if we need it to have an onClick
to toggle a menu that doesn't apply to it
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ah yeah this used to be the same code for desktop and mobile but not anymore. Good catch
display: none; | ||
|
||
@media screen and (min-width: 768px) { | ||
display: block; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
do we need to explicitly be setting display: block
on divs? they should just do that naturally
then we could reduce our style rules to only be applying the thing we want to change, when we want to apply them
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I did this to follow the design guideline to style mobile first, also for when the --medium-screens-and-up
css variable is added back.
packages/site/src/layout/NavMenu.tsx
Outdated
return ( | ||
<> | ||
<div className={styles.desktopNavContainer}>{menuContent}</div> | ||
<div className={styles.mobileNavContainer}> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm getting a bit confused with these two classes called mobileNavContainer
what's this one for? if I delete it, as far as I can tell everything still works nicely
in general I'm having not the easiest time following what is showing/when with the combination of CSS display: none
and JS mediumAndUp
conditionals
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This mobileNavContainer is not needed since the visibility is controlled in LeftDrawer, I removed it.
I dont like mixing plain media query with useBreakpoints hook in js either. If we had to pick, is it fine to use div instead of Box in order to get all the responsive logic inside css?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Let me think about the combination of css and JS for a bit.
Overall the pattern I see is
- TopNav uses
mediumAndUp
only - NavMenu uses CSS media query only, except the logic where I dont attach
toggleMobileMenu
toLink
(but this has nothing to do with showing/hiding)
It's not really that convoluted anymore. Thoughts?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
definitely improved now that we're using some logic in React to avoid rendering
I think there's a world where we would be able to simply not render anything we don't want to render on a given screen size and it's all managed through one mechanism. however, it's not a huge priority since we're not particularly worried about rendering any of these nav components and the CSS cases that hide them are not too bad to follow.
…nu is set in LeftDrawer
…1-integrate-triton-to-next-gen-docs
….com:GetJobber/atlantis into JOB-115212-hide-nav-and-add-hamburger-to-collapse-side-nav
…2-hide-nav-and-add-hamburger-to-collapse-side-nav
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
Motivations
We want to make the Atlantis doc site mobile responsive
Changes
TopNav
layout changes during narrow viewportNavMenu
layout - move Jobber logo next to the close button in narrow viewporttoggleMobileMenu
onClick handler to every react-router-dom Link in NavMenu to close nav when clicked. The state update is only triggered if viewport is below medium.Added
LeftDrawer
is a simplified SideDrawer for the purpose of this responsive navisMobileMenuOpen
state in AtlantisSiteContextChanged
NavMenu
contains both the desktop nav and mobile navDeprecated
Removed
Fixed
Security
Testing
Changes can be
tested via Pre-release
The breakpoint is 768px. Test the responsiveness in TopNav, as well as NavMenu (which can be opened from the hamburger menu button)
In Atlantis we use Github's built in pull request reviews.