Skip to content
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

Merged
merged 5 commits into from
Sep 13, 2022

Conversation

KaylaBrady
Copy link
Contributor

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.

@github-actions
Copy link

github-actions bot commented Sep 8, 2022

Coverage of commit 49fa003

Summary coverage rate:
  lines......: 94.0% (2447 of 2604 lines)
  functions..: 72.8% (1030 of 1415 functions)
  branches...: no data found

Files changed coverage rate: n/a

Download coverage report

@KaylaBrady KaylaBrady temporarily deployed to dev-blue September 8, 2022 18:53 Inactive
<div className="m-nav--narrow">
<div
className="m-nav__nav-bar m-nav__nav-bar--top"
style={{ visibility: navVisibilityStyle }}
Copy link
Contributor Author

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!

Copy link
Member

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.

@github-actions
Copy link

github-actions bot commented Sep 9, 2022

Coverage of commit 1137fa4

Summary coverage rate:
  lines......: 94.0% (2447 of 2604 lines)
  functions..: 72.8% (1030 of 1415 functions)
  branches...: no data found

Files changed coverage rate: n/a

Download coverage report

@github-actions
Copy link

github-actions bot commented Sep 9, 2022

Coverage of commit 5971af0

Summary coverage rate:
  lines......: 94.0% (2447 of 2604 lines)
  functions..: 72.8% (1030 of 1415 functions)
  branches...: no data found

Files changed coverage rate: n/a

Download coverage report

@github-actions
Copy link

github-actions bot commented Sep 9, 2022

Coverage of commit 9487349

Summary coverage rate:
  lines......: 94.0% (2447 of 2604 lines)
  functions..: 72.8% (1030 of 1415 functions)
  branches...: no data found

Files changed coverage rate: n/a

Download coverage report

@KaylaBrady KaylaBrady temporarily deployed to dev-blue September 9, 2022 19:07 Inactive
@@ -13,6 +13,13 @@
@media screen and (max-width: $mobile-max-width) {
width: 100%;
}
@media screen and (max-width: $mobile-max-width) {
Copy link
Member

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.

Copy link
Contributor Author

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.

Copy link
Member

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.

position: fixed;
top: 0;
bottom: 0;
width: 100%;
Copy link
Member

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.

position: fixed;
top: 0;
bottom: 0;
width: 100%;
Copy link
Member

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.

@@ -27,6 +27,13 @@
}
}
}
@media screen and (max-width: $mobile-max-width) {
Copy link
Member

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.

@github-actions
Copy link

github-actions bot commented Sep 9, 2022

Coverage of commit 46803c3

Summary coverage rate:
  lines......: 94.0% (2447 of 2604 lines)
  functions..: 72.8% (1030 of 1415 functions)
  branches...: no data found

Files changed coverage rate: n/a

Download coverage report

Copy link
Member

@lemald lemald left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

👍

@github-actions
Copy link

github-actions bot commented Sep 9, 2022

Coverage of commit 46803c3

Summary coverage rate:
  lines......: 94.0% (2447 of 2604 lines)
  functions..: 72.8% (1030 of 1415 functions)
  branches...: no data found

Files changed coverage rate: n/a

Download coverage report

@KaylaBrady KaylaBrady temporarily deployed to dev-blue September 9, 2022 20:25 Inactive
@KaylaBrady KaylaBrady temporarily deployed to dev-blue September 12, 2022 18:20 Inactive
@KaylaBrady KaylaBrady temporarily deployed to dev-blue September 12, 2022 19:26 Inactive
@KaylaBrady KaylaBrady temporarily deployed to dev-blue September 12, 2022 19:26 Inactive
@KaylaBrady KaylaBrady merged commit f3f2e36 into master Sep 13, 2022
@KaylaBrady KaylaBrady deleted the kb-mobile-vpp-scroll-fix branch September 13, 2022 16:53
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants