-
Notifications
You must be signed in to change notification settings - Fork 236
fix(compass-components): improve dark theme toggle appearance COMPASS-5470 #2751
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
Changes from all commits
3dda3fd
f1bee25
5163c31
b19d81c
bccd0c6
dad2a58
6591e0e
346d632
6890316
d3f8eca
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Some generated files are not rendered by default. Learn more about how customized files appear on GitHub.
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,14 @@ | ||
import React from 'react'; | ||
import LeafyGreenToggle from '@leafygreen-ui/toggle'; | ||
|
||
import { Theme, useTheme } from '../hooks/use-theme'; | ||
|
||
function Toggle( | ||
props: React.ComponentProps<typeof LeafyGreenToggle> | ||
): ReturnType<typeof LeafyGreenToggle> { | ||
const theme = useTheme(); | ||
|
||
return <LeafyGreenToggle darkMode={theme?.theme === Theme.Dark} {...props} />; | ||
} | ||
Comment on lines
+6
to
+12
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Raised this with leafygreen, if that's the only way to set the darkMode for their components, we are at the risk of wrapping every single leafygreen component that we export here which sounds like a giant maintenance headache There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. yes it would be better if they'd have a provider we can use, I'd expect LG to also provide themes and guidelines for the palette, which is something we'd have to do on our side otherwise:
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. We could do something like this before re-exporting the components on our side:
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I mean, yeah, we totally can do something like that, HOC is indeed a good pattern to use here. It's just weird that we have to even though we all agree that we want to do as little changes to leafygreen as possible There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. lg team said this will be addressed when they are eventually working on a dark mode support There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. What should we do for now? I think we probably won't need to do many fixes like this until dark theme/the new provider is released in leafygreen so having one component listening to the theme is probably alright? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I would merge this as it is |
||
|
||
export { Toggle }; |
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,32 @@ | ||
import React, { createContext, useContext } from 'react'; | ||
|
||
export enum Theme { | ||
Light = 'Light', | ||
Dark = 'Dark', | ||
} | ||
|
||
type ThemeState = { | ||
Anemy marked this conversation as resolved.
Show resolved
Hide resolved
|
||
theme: Theme; | ||
}; | ||
|
||
const ThemeContext = createContext<ThemeState>({ | ||
theme: Theme.Light, | ||
}); | ||
|
||
const ThemeProvider = ({ | ||
children, | ||
theme, | ||
}: { | ||
children: React.ReactChildren; | ||
theme: ThemeState; | ||
}): React.ReactElement => { | ||
return ( | ||
<ThemeContext.Provider value={theme}>{children}</ThemeContext.Provider> | ||
); | ||
}; | ||
|
||
function useTheme(): ThemeState { | ||
return useContext(ThemeContext); | ||
} | ||
|
||
export { useTheme, ThemeProvider }; |
Uh oh!
There was an error while loading. Please reload this page.
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.
Do we want to to be overridable like that? What should take precedence?
Uh oh!
There was an error while loading. Please reload this page.
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.
Good question. I think we probably want it to be overrideable, yes, but I'm alright with either approach. If it's a component which always is displayed in a darkMode or always needs to be light mode I think we'll want to customize it and override the provider. I think we could also add more providers in that situation, but if it's just one component I think it's simpler to just override this. I'm cool with either here - is there one you prefer?
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.
Yeah, this makes sense! Let's keep it like that for now 👍