-
-
Notifications
You must be signed in to change notification settings - Fork 444
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
Conversation
There was a problem hiding this comment.
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> |
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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); |
There was a problem hiding this comment.
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; | ||
} |
There was a problem hiding this comment.
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!, |
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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"> |
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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"> |
There was a problem hiding this comment.
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" |
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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') |
There was a problem hiding this comment.
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) => { |
There was a problem hiding this comment.
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) { |
There was a problem hiding this comment.
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
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
be86363
to
4786c30
Compare
This PR is a refactor to cleanup the code related to the Sidebar component.
I does a few things:
SidebarItem
component, so we don't need to use<button>
andNavLink
directly in SidebarLinks (this helps remove a lot of duplication around creating those items)sidebar.css
file that is easier to find in each component's css, we also had css forSidebar__item
in multiple css files)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 theuseSettingsContext
context and theSettings
screen to remove the code that was using thatHow 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):
Use the following Checklist if you have changed something on the Backend or Frontend: