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: header breaks on mobile screens #374

Merged
merged 14 commits into from
Jul 17, 2023
Merged

fix: header breaks on mobile screens #374

merged 14 commits into from
Jul 17, 2023

Conversation

hashrock
Copy link
Contributor

This pull request introduces a hamburger menu on mobile.

Close #345

Implementation notes:

  • I had to use descendant selectors and adjacent selectors to implement a pure CSS hamburger menu. This required using twind-preset-ext in Twind v1.
  • Two newly added icons use heroicons.
  • Requires few line of inline JS to be accessible with keyboard.

before:

image image

after:

image image image

@hashrock hashrock requested a review from iuioiua July 14, 2023 15:03
Copy link
Contributor

@iuioiua iuioiua left a comment

Choose a reason for hiding this comment

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

Looking good! Just a few technical concerns.

Comment on lines 21 to 35
function MenuItem(props: MenuItemProps) {
return (
<a
href={props.href}
class={cx(
props.active ? ACTIVE_LINK_STYLES : LINK_STYLES,
"relative text-gray-500 px-3 py-4 sm:py-2",
props.class,
)}
aria-label={props.ariaLabel}
>
{props.name}
</a>
);
}
Copy link
Contributor

Choose a reason for hiding this comment

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

I think it'd be cleaner if we just wrote the menu HTML without iterating over an array of elements. Menu items can vary in requirements, making a flexible <MenuItem /> challenging to manage past a certain point. We can have a MENU_ITEM_STYLES constant for any common styles between these menu items. WDYT?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Hmm I wanted to use the practice of defining menus with JSON, which used in our repos (Example), but okay let me revert last refactoring commit. let's discuss this in another PR

import { Bell, CircleFilled } from "./Icons.tsx";
import { getToggledStyles } from "@/utils/display.ts";
import { Bars, Bell, CircleFilled, Cross } from "./Icons.tsx";
import { cx } from "@twind/core";
Copy link
Contributor

Choose a reason for hiding this comment

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

Sidenote: this might be able to replace the new getToggledStyles().

Copy link
Contributor Author

@hashrock hashrock Jul 17, 2023

Choose a reason for hiding this comment

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

Yes, we can use it. I was just writing code like this at first:

class={cx(
  getToggledStyles(
    LINK_STYLES,
    ACTIVE_LINK_STYLES,
    props.url.pathname === "/pricing",
  ),
  NAV_ITEM,
)}

I noticed that this code can be rewritten as:

class={cx(
  props.url.pathname === "/pricing" ? ACTIVE_LINK_STYLES : LINK_STYLES,
  NAV_ITEM,
)}

This cx style description is used in deno deploy and can handle both concatenation and toggle of CSS strings.
Since this header component uses cx throughout, I removed getToggledStyles as a dependency.

I think it would be better to write getToggledStyles with a ternary operator where cx is used, what do you think?

Copy link
Contributor

@iuioiua iuioiua Jul 17, 2023

Choose a reason for hiding this comment

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

What about if we got rid of getToggledStyles() completely across the codebase and used cx() instead? Maybe we could do this in another PR.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

yeah if it's okay, I'll like to help to do this

href={props.href}
class={cx(
props.active ? ACTIVE_LINK_STYLES : LINK_STYLES,
"relative text-gray-500 px-3 py-4 sm:py-2",
Copy link
Contributor

Choose a reason for hiding this comment

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

Suggested change
"relative text-gray-500 px-3 py-4 sm:py-2",
"relative text-gray-500 py-4 sm:py-2",

Perhaps, we don't need any horizontal padding. WYDT?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Hmm, maybe removing the padding makes the spacing a little too tight.

image

I think padding is necessary in order to widen the clickable area of the target.

with no padding:

image

with padding:

image

components/Header.tsx Show resolved Hide resolved
components/Header.tsx Show resolved Hide resolved
@brunocorrea23
Copy link
Contributor

Looks great!
Suggestion: as it is such an important element of the UI, would it be better to leave the submit button outside the hamburger menu (ie: always visible)?

href: "/account/notifications",
ariaLabel: "Notifications",
},
{ name: "Submit a project", href: "/submit", class: "sm:hidden" },
Copy link
Contributor

Choose a reason for hiding this comment

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

Suggested change
{ name: "Submit a project", href: "/submit", class: "sm:hidden" },
{ name: "Submit", href: "/submit", class: "sm:hidden" },

I'm happy to keep the inner text the same.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Isn't it a little vague what to do if the label is just "Submit"? In PH, the label is only Submit, but the target is selected by hover.

image

Rather, what if the header button to say "Submit a project" when it is wide enough?

@iuioiua
Copy link
Contributor

iuioiua commented Jul 16, 2023

Looks great! Suggestion: as it is such an important element of the UI, would it be better to leave the submit button outside the hamburger menu (ie: always visible)?

I'd prefer to keep it in the menu as it is now. Instead, perhaps we could keep its button styling to stand out. WDYT?

Co-authored-by: Asher Gomez <ashersaupingomez@gmail.com>
@hashrock
Copy link
Contributor Author

image

@iuioiua OK, wdyt?

Copy link
Contributor

@iuioiua iuioiua left a comment

Choose a reason for hiding this comment

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

This looks amazing 😍

@iuioiua
Copy link
Contributor

iuioiua commented Jul 17, 2023

I'll merge. Let's have the cx() discussion elsewhere, it needed.

@iuioiua iuioiua merged commit 1c0ccd5 into main Jul 17, 2023
@iuioiua iuioiua deleted the fix-header-mobile branch July 17, 2023 11:24
@hashrock
Copy link
Contributor Author

Thank you!

iuioiua pushed a commit that referenced this pull request Feb 23, 2024
"Someone" broke the hamburger menu in #646.

This fixes the issue and cleans things up by making the CSS a bit more
direct:
* I use
https://tailwindcss.com/docs/hover-focus-and-other-states#styling-based-on-sibling-state
to modify the `nav` directly.
* I add IDs to the hamburger and X components, and then use
https://tailwindcss.com/docs/hover-focus-and-other-states#using-arbitrary-variants
to directly target them, in combination with peer.

FYI @hashrock since this restores the great work you did in #374.
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.

bug: header breaks on mobile screens
3 participants