-
Notifications
You must be signed in to change notification settings - Fork 7
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
fix(MobilePortraitNav): use single grid layout to prevent scroll position resetting when a view is opened #1719
Conversation
…tion resetting when a view is opened
Coverage of commit
|
… size adjustments of the route ladder
a7b6927
to
1137fa4
Compare
<div className="m-nav--narrow"> | ||
<div | ||
className="m-nav__nav-bar m-nav__nav-bar--top" | ||
style={{ visibility: navVisibilityStyle }} |
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 opted to do inline styling here as a work around for this issue w/ jest toBeVisible not working with separate stylesheets unless there is some css configuration work done. If there is a preferred alternative approach I'd be open to trying 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.
My usual approach for these things has been to set a class based on the condition in question, and then just assert the presence / absence of the relevant classes on the element in my tests. This works, too, though, and toBeVisible
actually tests the relevant property more directly.
Coverage of commit
|
6a024ca
to
5971af0
Compare
5971af0
to
9487349
Compare
Coverage of commit
|
Coverage of commit
|
assets/css/_notification_drawer.scss
Outdated
@@ -13,6 +13,13 @@ | |||
@media screen and (max-width: $mobile-max-width) { | |||
width: 100%; | |||
} | |||
@media screen and (max-width: $mobile-max-width) { |
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.
Is $mobile-max-width
actually the correct value? It's defined in app.scss
as 768px and it was a breakpoint used in most old Skate designs, but it's not the same as the breakpoint for mobile portrait nav.
On the other hand, if it is supposed to be $mobile-max-width
, this can be combined with the above selector / 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.
Good call this is not the right value - as-is, shrinking to a window between 480-768px wide produces a broken mashup of navs. I'll introduce a new $mobile-portrait-max-width
variable and reference that instead.
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.
For what it's worth, the breakpoints for the new nav are defined in src/hooks/useDeviceType.ts
. Since the nav logic happens largely in JavaScript, I didn't end up creating new SCSS constants for the breakpoints. I think eventually we want to retire the use of the existing $mobile-max-width
and make all of the different breakpoints consistent.
assets/css/_notification_drawer.scss
Outdated
position: fixed; | ||
top: 0; | ||
bottom: 0; | ||
width: 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.
It should have the same outcome, but I wonder if 100vw
would be a bit clearer about the fact that the intent is to take up all of the horizontal space on the screen. I don't think we're actually consistent one way or another in the existing CSS about when we use vw
/ vh
.
assets/css/_properties_panel.scss
Outdated
position: fixed; | ||
top: 0; | ||
bottom: 0; | ||
width: 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.
Other comments from above apply here, but also note that the width: 100%
here is redundant with width: 100vw
in the block above.
assets/css/_swings_view.scss
Outdated
@@ -27,6 +27,13 @@ | |||
} | |||
} | |||
} | |||
@media screen and (max-width: $mobile-max-width) { |
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.
See same question as above about $mobile-max-width
.
Coverage of commit
|
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.
👍
Coverage of commit
|
ticket: https://app.asana.com/0/1148853526253437/1202946731207901/f
The issue seemed to be that when opening the VPP, the page was rendered with a new grid, which seemed to reset the scroll position of the ladder page.
I'm not sure that the approach I've taken here is the cleanest one. My intention was to fix the issue without having to introduce storing the scroll position in state. By using one grid class and conditionally hiding the top / bottom navs, the scroll reset issue is no longer a problem. If there is a cleaner or more conventional approach here I am certainly open to changing!
I also wasn't sure of the best way to introduce a regression test for this - there is already test coverage to make sure the navs are conditionally shown / hidden, but maintaining scroll position seems like it might require using something like Cypress.