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

[Refactor] Sidebar cleanup (and a bit more that's related) #3544

Merged
merged 13 commits into from
Dec 14, 2024

Conversation

arielj
Copy link
Collaborator

@arielj arielj commented Feb 10, 2024

This PR is a refactor to cleanup the code related to the Sidebar component.

I does a few things:

  • Extracted a new SidebarItem component, so we don't need to use <button> and NavLink directly in SidebarLinks (this helps remove a lot of duplication around creating those items)
  • Replaced the .scss files with .css, we are not really using any sass feature
  • Refactored the css files to use native css nesting and moved the styles to the corresponding components' css (we had a lot of css in the main sidebar.css file that is easier to find in each component's css, we also had css for Sidebar__item in multiple css files)
  • I added new CSS properties specific to the sidebar that can help when theming, they fallback to what we already had so nothing changes, but new themes can use better variables that don't cause unexpected side effect
  • Because of this cleanup, I had to remove the state: { fromGameCard: ...} that was not really used anymore since the settings for a game were moved to the SettingsModal component. This led into some changes needed also in the useSettingsContext context and the Settings screen to remove the code that was using that

How to test/qa this

The sidebar should behave the same way as before (I didn't really change any CSS, I just moved things to different places and added nesting, and the new custom properties have fallbacks to the previous values):

  • Resizing
  • Hiding content during resize
  • sizes, colors, etc depending on the theme
  • etc

Use the following Checklist if you have changed something on the Backend or Frontend:

  • Tested the feature and it's working on a current and clean install.
  • Tested the main App features and they are still working on a current and clean install. (Login, Install, Play, Uninstall, Move games, etc.)
  • Created / Updated Tests (If necessary)
  • Created / Updated documentation (If necessary)

@arielj arielj added the pr:ready-for-review Feature-complete, ready for the grind! :P label Feb 10, 2024
@arielj arielj requested review from a team, flavioislima, CommandMC, Etaash-mathamsetty, Nocccer and imLinguin and removed request for a team February 10, 2024 17:21
Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Most of this file is the previous index.scss file renamed and adding the .Sidebar { nesting, and some new code extracted from the Sidebar/index.css file that fits better here

</Box>
</Box>
</div>
</Link>
Copy link
Collaborator Author

Choose a reason for hiding this comment

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

This is just me removing the extra <> fragment that was not needed, the diff is just the indentation

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

The code here is just CSS extracted from Sidebar/index.css, and refactored to use nesting

--navbar-active,
var(--accent-overlay, var(--accent))
);
--sidebar-active-item-background: var(--navbar-active-background);
Copy link
Collaborator Author

@arielj arielj Feb 10, 2024

Choose a reason for hiding this comment

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

this file is mostly extraction of Sidebar__item styles that were in other places, but I also added these new custom properties to help themes

margin-block: 0 var(--sidebar-vertical-padding);
margin-inline: var(--sidebar-horizontal-padding) var(--space-3xs);
-webkit-app-region: no-drag;
}
Copy link
Collaborator Author

Choose a reason for hiding this comment

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

I'm still keeping these types of properties here in the parent and not in the component's css because these styles should be controlled by the parent since they are styles "outside" the component

@@ -21,7 +21,7 @@ export default function Winetricks({ onClose }: Props) {
setLoading(true)
try {
const components = await window.api.winetricksListInstalled(
runner,
runner!,
Copy link
Collaborator Author

Choose a reason for hiding this comment

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

This is not needed because runner can be undefined in the Settings Context, but cannot be undefined in this case (we would never show the winetricks option anywhere without a game, so runner would be defined

Copy link
Collaborator

Choose a reason for hiding this comment

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

It'd be more robust if you'd pass the runner via this component's props (and then only take a Runner, not a Runner | undefined). You'd then not need these assertions

Assertions like this are dangerous, since if we ever change the conditions for showing this component (to no longer look at the context's runner), this will silently break

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

I'll updated the if (....) that we have above in this component to not render anything if we don't have a runner (we already render <></> when isDefault which implies runner is undefined, but making that explicit will get rid of these !)

className="backButton"
state={{ gameInfo: gameInfo }}
>
<NavLink to="/" role="link" className="backButton">
Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Since we moved the settings for specific games into a modal, this was always / anyway, we don't need all the code to detect to go back to a game page because that doesn't happen anymore

Copy link
Collaborator

Choose a reason for hiding this comment

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

This should go to /library for now (until #3540 is merged). Navigating to / just navigates to /library with an extra re-render

className="backButton"
state={{ gameInfo: gameInfo }}
>
<NavLink to="/" role="link" className="backButton">
Copy link
Collaborator

Choose a reason for hiding this comment

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

This should go to /library for now (until #3540 is merged). Navigating to / just navigates to /library with an extra re-render

</span>
</NavLink>
<SidebarItem
url="/settings/app/default/general"
Copy link
Collaborator

Choose a reason for hiding this comment

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

This url seems incorrect; shouldn't it be /settings/app/default/games_settings? Right now, both the "General" and "Game Defaults" buttons link to the same place

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

yep, wrong link, I'll actually do a bit more refactoring, we don't really need the app/default part of these urls anymore

@@ -1676,7 +1676,7 @@ ipcMain.on('processShortcut', async (e, combination: string) => {
break
// hotkey to open the settings on frontend
case 'ctrl+k':
sendFrontendMessage('openScreen', '/settings/app/default/general')
sendFrontendMessage('openScreen', '/settings/general')
Copy link
Collaborator Author

Choose a reason for hiding this comment

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

we don't need these app/default routes anymore, the Settings component always renders Heroic's settings, game's settings are not handled by this url

return <></>
}

type Tool = 'winecfg' | string
async function callTools(tool: Tool, exe?: string) {
const callTools = async (tool: Tool, exe?: string) => {
Copy link
Collaborator Author

Choose a reason for hiding this comment

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

I had to change these to arrow functions because the typescript complains about runner being possible undefined inside function() (even though this happens after the if)

looks like, because this is different in the 2 cases, runner can be undefined for named functions but it's correct with arrow functions

})

// render `loading` while we fetch the settings
if (!title || !contextValues) {
if (!currentConfig || !contextValues) {
Copy link
Collaborator Author

Choose a reason for hiding this comment

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

we were checking title here, but title doesn't really change, it's better to check for currentConfig since it's what the comment is saying originally and that's the real intention

@arielj arielj requested a review from CommandMC February 16, 2024 18:49
@arielj arielj mentioned this pull request Apr 2, 2024
4 tasks
Copy link
Member

@flavioislima flavioislima left a comment

Choose a reason for hiding this comment

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

LGTM

@arielj arielj force-pushed the refactor-sidebar-cleanup branch from be86363 to 4786c30 Compare December 14, 2024 01:52
@arielj arielj merged commit a1a6f4a into main Dec 14, 2024
9 checks passed
@arielj arielj deleted the refactor-sidebar-cleanup branch December 14, 2024 02:22
@Heroic-Games-Launcher Heroic-Games-Launcher locked and limited conversation to collaborators Dec 14, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
pr:ready-for-review Feature-complete, ready for the grind! :P
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants