Update the mobile header menu nav width for large mobile screen size

[aralovelace]

Jira Ticket Link / Motivation

WEB-3842 - Update the mobile header to have a different width for large mobile screen size as one of the design requirement for the Meganav mobile view design here

Summary of changes

This pull request includes a change to the src/core/Header.tsx file to improve the layout and responsiveness of the mobile menu. The most important change involves modifying the CSS class and inline styles to better handle the menu's width and maximum height.

Changes to improve layout and responsiveness:

• src/core/Header.tsx: Updated the mobile-menu div's CSS class to set the width to calc(100%-24px) and added a maxWidth inline style of 560px to ensure the menu does not exceed this width.

How do you manually test this?

View the header and changed to tablet view and the width should not be in full width

Reviewer Tasks (optional)

Merge/Deploy Checklist

• Written automated tests for implemented features/fixed bugs
• Rebased and squashed commits
• Commits have clear descriptions of their changes
• Checked for any performance regressions

Frontend Checklist

• No frontend changes in this PR
• Added before/after screenshots for changes
• Tested on different platforms/browsers with Browserstack
• Compared with the initial design / our brand guidelines
• Checked the code for accessibility issues (VoiceOver User Guide)?

Summary by CodeRabbit

Summary by CodeRabbit

• Style
  • Improved mobile menu responsiveness with updated width and positioning, enhancing the display on extra small and small screens.
  • Added a maximum width constraint to the mobile menu for better control over its appearance.

[coderabbitai]

Important

Review skipped

Auto incremental reviews are disabled on this repository.

Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Walkthrough

This pull request introduces a new constant MAX_MOBILE_MENU_WIDTH in the Header.tsx component, which is set to 584 pixels. This constant is utilized in the handleResize function to adjust the mobile menu's width and positioning based on the current window size. If the window width is less than this constant, the mobile menu's width is set to "auto" and its left position to "0"; otherwise, it expands to "100%" with the left position set to "auto". The mobile menu's class definition has also been updated to include a max-w-[560px] constraint.

Changes

File	Change Summary
src/core/Header.tsx	Added constant MAX_MOBILE_MENU_WIDTH = 584, updated handleResize function for dynamic mobile menu width and positioning based on window size, and modified mobile menu class to include max-w-[560px].

Possibly related PRs

• [WEB-4082] Divide header into three equal parts #649: Modifications in Header.tsx for a responsive mobile menu layout.

Suggested labels

review

Suggested reviewers

• jamiehenson

Poem

I'm a rabbit with a keen new sight,
Hoping through code with joy and delight.
Mobile menus now stretch and play,
Adapting smoothly every day.
Carrots and code—hoppy design in flight!
🥕🐰

---

🪧 Tips

Chat

There are 3 ways to chat with CodeRabbit:

• Review comments: Directly reply to a review comment made by CodeRabbit. Example:
  • I pushed a fix in commit <commit_id>, please review it.
  • Generate unit testing code for this file.
  • Open a follow-up GitHub issue for this discussion.
• Files and specific lines of code (under the "Files changed" tab): Tag @coderabbitai in a new review comment at the desired location with your query. Examples:
  • @coderabbitai generate unit testing code for this file.
  • @coderabbitai modularize this function.
• PR comments: Tag @coderabbitai in a new PR comment to ask questions about the PR branch. For the best results, please provide a very specific query, as very limited context is provided in this mode. Examples:
  • @coderabbitai gather interesting stats about this repository and render them as a table. Additionally, render a pie chart showing the language distribution in the codebase.
  • @coderabbitai read src/utils.ts and generate unit testing code.
  • @coderabbitai read the files in the src/scheduler package and generate a class diagram using mermaid and a README in the markdown format.
  • @coderabbitai help me debug CodeRabbit configuration file.

Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments.

CodeRabbit Commands (Invoked using PR comments)

• @coderabbitai pause to pause the reviews on a PR.
• @coderabbitai resume to resume the paused reviews.
• @coderabbitai review to trigger an incremental review. This is useful when automatic reviews are disabled for the repository.
• @coderabbitai full review to do a full review from scratch and review all the files again.
• @coderabbitai summary to regenerate the summary of the PR.
• @coderabbitai generate docstrings to generate docstrings for this PR. (Beta)
• @coderabbitai resolve resolve all the CodeRabbit review comments.
• @coderabbitai configuration to show the current CodeRabbit configuration for the repository.
• @coderabbitai help to get help.

Other keywords and placeholders

• Add @coderabbitai ignore anywhere in the PR description to prevent this PR from being reviewed.
• Add @coderabbitai summary to generate the high-level summary at a specific location in the PR description.
• Add @coderabbitai anywhere in the PR title to generate the title automatically.

CodeRabbit Configuration File (.coderabbit.yaml)

• You can programmatically configure CodeRabbit by adding a .coderabbit.yaml file to the root of your repository.
• Please see the configuration documentation for more information.
• If your editor has YAML language server enabled, you can add the path at the top of this file to enable auto-completion and validation: # yaml-language-server: $schema=https://coderabbit.ai/integrations/schema.v2.json

Documentation and Community

• Visit our Documentation for detailed information on how to use CodeRabbit.
• Join our Discord Community to get help, request features, and share feedback.
• Follow us on X/Twitter for updates and announcements.

[aralovelace]

@jamiehenson I’m not sure if this matches the requirements in the docs. If not, could we pass mobile class names so I can apply these styles? I just add the classes directly for now in this PR

[jamiehenson]

Looking at the designs for the meganav, I see the requirement here. Yeah I'm not sure about the docs situation either as there were no designs for the md (i.e. tablet) range so we currently use the mobile behaviour for the tablet range as well, as you know. This didn't come up in the design feedback though, perhaps Jamie hadn't settled on the meganav designs at that time.

It's up to Design as to whether we want the mobile nav behaviour (i.e. what you're striving for here) to be consistent across both cases or not. If not, you're right in that we'll need a prop to differentiate.

In terms of what's here, the CSS approach isn't right - it doesn't match the behaviour in the Figma prototype. This follows on from recent conversations in that we shouldn't just use approximate percentages for widths. Looking at the designs, the mobile nav has a maximum width of 560px that naturally collapses when the viewport is narrower than 560, so this is a matter of right aligning and conditionally (or not conditionally, depending on what design say) setting a max width.

[aralovelace]

@coderabbitai review

[coderabbitai]

✅ Actions performed

Review triggered.

Note: CodeRabbit is an incremental review system and does not re-review already reviewed commits. This command is applicable only when automatic reviews are paused.

[aralovelace]

Looking at the designs for the meganav, I see the requirement here. Yeah I'm not sure about the docs situation either as there were no designs for the md (i.e. tablet) range so we currently use the mobile behaviour for the tablet range as well, as you know. This didn't come up in the design feedback though, perhaps Jamie hadn't settled on the meganav designs at that time.

It's up to Design as to whether we want the mobile nav behaviour (i.e. what you're striving for here) to be consistent across both cases or not. If not, you're right in that we'll need a prop to differentiate.

In terms of what's here, the CSS approach isn't right - it doesn't match the behaviour in the Figma prototype. This follows on from recent conversations in that we shouldn't just use approximate percentages for widths. Looking at the designs, the mobile nav has a maximum width of 560px that naturally collapses when the viewport is narrower than 560, so this is a matter of right aligning and conditionally (or not conditionally, depending on what design say) setting a max width.

Thanks @jamiehenson for the feedback! I’ve already applied your comment to match the Figma prototype. The mobile nav now has a max width of 560px and collapses naturally when the viewport is narrower.

For the matter if it is applicable to docs as well, now waiting from Jamie W for his response.

[jamiehenson]

Good thinking with the use of the MAX_MOBILE_MENU_WIDTH constant, but we can do this more straightforwardly and without the use of JS.

• we don't need to worry about left, as the component is right aligned and so we're not interested in its left alignment
• with w-[calc(100%-24px)], we factor in the component margins into the width calculation. I don't think we need to constantise this as it's only used here, but take a look at some similar stuff I do in this helper file that's about setting heights as a sign of where to take this if we want to do more with calculating widths later
• may as well keep that max width constant alive by replacing max-w-[560px] with an assignment to maxWidth in the style prop. Can also make the constant 560 as with the above the margin no longer has to be factored into the value

[aralovelace]

Good thinking with the use of the MAX_MOBILE_MENU_WIDTH constant, but we can do this more straightforwardly and without the use of JS.

• we don't need to worry about left, as the component is right aligned and so we're not interested in its left alignment
• with w-[calc(100%-24px)], we factor in the component margins into the width calculation. I don't think we need to constantise this as it's only used here, but take a look at some similar stuff I do in this helper file that's about setting heights as a sign of where to take this if we want to do more with calculating widths later
• may as well keep that max width constant alive by replacing max-w-[560px] with an assignment to maxWidth in the style prop. Can also make the constant 560 as with the above the margin no longer has to be factored into the value

you are amazing @jamiehenson ! I made it super complicated that will solve it w-[calc(100%-24px)] thank you! I think I was stuck to the solution of w-auto and w-full that have to add JS. It is now updated and noted with the helper file for the future.

[jamiehenson]

Nice - just a comment about how best to set the max width but good to go after that 👍