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: hidden settings menu affects settings layout #7769

Merged

Conversation

Khaan25
Copy link
Contributor

@Khaan25 Khaan25 commented Oct 17, 2024

This PR fixes #6746

Copy link

github-actions bot commented Oct 17, 2024

Welcome!

Hello there, congrats on your first PR! We're excited to have you contributing to this project.
By submitting your Pull Request, you acknowledge that you agree with the terms of our Contributor License Agreement.

Generated by 🚫 dangerJS against c0c8f2d

Copy link
Contributor

@greptile-apps greptile-apps bot left a comment

Choose a reason for hiding this comment

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

PR Summary

This pull request addresses an issue where hiding the left navigation menu affects the layout of the Settings page, causing it to shift to the left.

  • Added useIsRoute hook in packages/twenty-front/src/utils/currentPage.ts to check if the current route matches a given path
  • Modified PageHeader component in packages/twenty-front/src/modules/ui/layout/page/PageHeader.tsx to conditionally render the NavigationDrawerCollapseButton based on the current route
  • Prevents NavigationDrawerCollapseButton from rendering on the Settings page, fixing the layout issue when the left menu is hidden
  • Utilizes the new useIsRoute hook to determine if the current page is the Settings page

2 file(s) reviewed, 2 comment(s)
Edit PR Review Bot Settings | Greptile


return (
<StyledTopBarContainer width={width}>
<StyledLeftContainer>
{!isMobile && !isNavigationDrawerOpen && (
{!isMobile && !isNavigationDrawerOpen && !isSettingsPage && (
Copy link
Contributor

Choose a reason for hiding this comment

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

style: This condition now has multiple checks. Consider extracting it into a separate function for better readability

Comment on lines 8 to 11
export const useIsRoute = (path: string): boolean => {
const location = useLocation();
return location.pathname === path;
};
Copy link
Contributor

Choose a reason for hiding this comment

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

style: Consider using startsWith(path) instead of strict equality for more flexible route matching

* @param path The route to match.
* @returns True if the current route matches the given path, false otherwise.
*/
export const useIsRoute = (path: string): boolean => {
Copy link
Member

Choose a reason for hiding this comment

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

a few feedbacks about this file:

  1. we don't add JS doc in the project as we try to avoid comments and we are already using typescript to provide a nice dev xp. Function names should be clear enough to avoid doing it
  2. useIsRoute is a hook so it should not be in a utils folder
  3. I don't thin this s actually useful, we can just do useLocation().pathname === path whenever we need

Copy link
Member

Choose a reason for hiding this comment

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

So I would remove this hook actually

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Right. I'll remove it.

I was also thinking the same

@@ -109,11 +110,12 @@ export const PageHeader = ({
const isMobile = useIsMobile();
const theme = useTheme();
const isNavigationDrawerOpen = useRecoilValue(isNavigationDrawerOpenState);
const isSettingsPage = useIsRoute('/settings/profile');
Copy link
Member

Choose a reason for hiding this comment

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

we should not only check for settings/profile but for all settings route

Copy link
Member

Choose a reason for hiding this comment

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

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Thanks for the link, I'll have a look

Copy link
Member

@charlesBochet charlesBochet left a comment

Choose a reason for hiding this comment

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

Thanks @Khaan25, I have left comments :)

@@ -109,11 +110,12 @@ export const PageHeader = ({
const isMobile = useIsMobile();
const theme = useTheme();
const isNavigationDrawerOpen = useRecoilValue(isNavigationDrawerOpenState);
const isSettingsPage = useIsRoute('/settings/profile');
Copy link
Member

Choose a reason for hiding this comment

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

@Khaan25
Copy link
Contributor Author

Khaan25 commented Oct 18, 2024

There you go! @charlesBochet

const isNavigationDrawerExpanded = useRecoilValue(
isNavigationDrawerExpandedState,
);
const isNavigationDrawerOpen = useRecoilValue(isNavigationDrawerOpenState);
Copy link
Member

Choose a reason for hiding this comment

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

not sure why you changed the state name here

Copy link
Member

Choose a reason for hiding this comment

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

this is actually breaking the app

Copy link
Member

@charlesBochet charlesBochet left a comment

Choose a reason for hiding this comment

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

@Khaan25 Thanks for pushing changes/

  1. I have taken a new look and found that we actually already have a
    useIsSettingsPage hook

  2. fixing the state name (mentioned in comment), we are still having a blank Settings menu

image

@Khaan25
Copy link
Contributor Author

Khaan25 commented Oct 18, 2024

That's strange. I've tested it multiple times. Let me double check and get back to you.

Regarding the change, there was new code on the repo and I pulled in the latest changes.

@Khaan25
Copy link
Contributor Author

Khaan25 commented Oct 18, 2024

Here you go! @charlesBochet

It's fixed :) Let me know if there's any other issue with more points 😄You can assign me

2024-10-18.23-15-08.mp4

@Khaan25
Copy link
Contributor Author

Khaan25 commented Oct 19, 2024

Hey, could you review it? I can work on other issues?

@Khaan25
Copy link
Contributor Author

Khaan25 commented Oct 21, 2024

Hey @charlesBochet, could you please review :)

@charlesBochet
Copy link
Member

On it :)

// Check if the user is on the settings page and the navigation drawer is not expanded
// Then open it automatically
useEffect(() => {
if (!isNavigationDrawerExpanded && isSettingsPage) {
Copy link
Member

Choose a reason for hiding this comment

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

we don't put side effects in components as we don't want to encourage developers to implement behaviors during rendering (this is pushing them to take dependencies on variables and trigger re-renders). Instead, we either:

  • implement sync behaviors (in callbacks, event handlers, ...)
  • move useEffects to ComponentEffects that have no children so it's not a big deal from a performance perspective

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Right. I should be creating a custom hook to achieve it, right?

Copy link
Member

@charlesBochet charlesBochet left a comment

Choose a reason for hiding this comment

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

Current behavior is functional but I'm not a fan of this useEffect

@Khaan25
Copy link
Contributor Author

Khaan25 commented Oct 21, 2024

I believe that we need to have this useEffect because it's gonna only trigger it when we've settings page :)

I really thought about solving without useEffect but I ran into bugs as we've had before.

@@ -48,10 +42,6 @@ export const AppNavigationDrawer = ({
footer: <SupportDropdown />,
};

useEffect(() => {
Copy link
Member

Choose a reason for hiding this comment

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

another useEffect spotted :p

@Khaan25
Copy link
Contributor Author

Khaan25 commented Oct 21, 2024

Really amazing job here. It opened my eyes that we could really remove it 🙌

@@ -5,13 +5,24 @@ import { AppHotkeyScope } from '../types/AppHotkeyScope';

import { useSequenceHotkeys } from './useSequenceScopedHotkeys';

export const useGoToHotkeys = (key: Keys, location: string) => {
type GoToHotkeysProps = {
Copy link
Member

Choose a reason for hiding this comment

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

changing the API to take an object which is better from a dev XP as parameters are named when using the hook

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yes, I fully agree, Object is way more easier to debug and use.

I always to that :)

import { useLocation } from 'react-router-dom';
import { useRecoilCallback } from 'recoil';

export const GotoHotkeysEffectsProvider = () => {
Copy link
Member

Choose a reason for hiding this comment

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

I'm actually only renaming this file from GoToHokeysEffect

export const useGoToHotkeys = ({
key,
location,
preNavigateFunction,
Copy link
Member

Choose a reason for hiding this comment

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

passing a a preNavigationFunction to update the problematic state

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Could you please explain me how this part is working?

I mean we did avoid useEffect but how's it solving the problem?

@charlesBochet
Copy link
Member

charlesBochet commented Oct 21, 2024

@Khaan25 I have made some changes to avoid useEffects. Could you pull the changes and see if the functional behavior looks good?

@Khaan25
Copy link
Contributor Author

Khaan25 commented Oct 21, 2024

Sure, let me try

@Khaan25
Copy link
Contributor Author

Khaan25 commented Oct 21, 2024

Running the app locally is causing this issue:
image

@charlesBochet
Copy link
Member

@Khaan25 I can't reproduce, what are you doing to get this error?

@charlesBochet
Copy link
Member

I think we are good, I'll merge it :)

@charlesBochet charlesBochet merged commit 5e2df81 into twentyhq:main Oct 21, 2024
16 checks passed
Copy link

oss-gg bot commented Oct 21, 2024

Awarding Khaan25: 150 points 🕹️ Well done! Check out your new contribution on oss.gg/Khaan25

@Khaan25
Copy link
Contributor Author

Khaan25 commented Oct 22, 2024

I just ran the twenty-front, maybe it's cache or something. Will try again and let you know it gives error again

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Hidden left menu affects Settings layout
2 participants