-
Notifications
You must be signed in to change notification settings - Fork 29
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
Dark mode functionality - by Claude #1022
base: trunk
Are you sure you want to change the base?
Conversation
- Create ThemeModeProvider for managing light/dark/system theme preferences - Implement user preferences storage in user data - Add dark mode styles for UI components in Tailwind and CSS - Create theme toggle control in user settings panel - Support system theme preference detection
- Create custom theme icons since the sun and moon icons aren't available in @wordpress/icons - Add missing getUserPreference and saveUserPreference methods to IPC API interface
This commit improves dark mode styling throughout the app, with a focus on: 1. Fixed modal styling for Add Site modal by adding body.dark selectors 2. Enhanced form controls with proper dark mode colors for text inputs, borders, and placeholder text 3. Improved site form elements in dark mode including folder icons, help text, and borders 4. Added dark mode support for button variants to ensure proper styling in all contexts 5. Fixed text colors and contrast ratios for better readability in dark mode 🤖 Generated with [Claude Code](https://claude.ai/code) Co-Authored-By: Claude <[email protected]>
![]() Not sure I like the background color too much but I guess it works for people that like Dark mode. cc @matt-west for design input. |
@@ -0,0 +1,25 @@ | |||
# WordPress Studio Development Guide |
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 should probably remove that file, I'm not sure we should be adding the config files/intructions for all the AIs at the moment.
|
||
export const ThemeModeProvider = ({ children }: { children: ReactNode }) => { | ||
const [themeMode, setThemeModeState] = useState<ThemeMode>('system'); | ||
const [isDarkMode, setIsDarkMode] = useState(false); |
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 might worth consolidating theme state with language state at some point instead of local state that is spread between multiple Providers/hooks.
Ideally all the preferences are handled in the same low level abstraction/way.
It's fine to be a follow-up I would say but let's not let this kind of thing slip.
props.className | ||
) } | ||
/> | ||
); | ||
}; | ||
|
||
export default TextControlComponent; | ||
export default TextControlComponent; |
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.
Why? :)
</I18nDataProvider> | ||
</ReduxProvider> | ||
</ErrorBoundary> | ||
); | ||
}; | ||
export default Root; | ||
export default Root; |
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.
why?
.dark .assistant-markdown hr { | ||
border-top: 1px solid theme( 'colors.gray.700' ); | ||
} | ||
|
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.
Feels like there's a lot of CSS overrides for dark mode, I wonder if there's a way to avoid all of that by using CSS variables.
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.
Heavy +1. These CSS overrides will be incredibly difficult to maintain as we add new features. It also makes it harder to introduce new themes in the future (i.e. high contrast, custom user themes).
@@ -1159,3 +1159,18 @@ export async function isFullscreen( _event: IpcMainInvokeEvent ): Promise< boole | |||
const window = await getMainWindow(); | |||
return window.isFullScreen(); | |||
} | |||
|
|||
export async function getUserPreference( _event: IpcMainInvokeEvent, key: string ): Promise< unknown > { |
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 not sure we need these two functions or the nested "preferences" key. For the "locale", there's no nested "preferences" key, so I think we should just map what we're doing for the user's "locale".
I noticed that some modals apply dark mode (add site) but others don't (edit site, user preferences, connect site) |
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.
Thanks for the ping @youknowriad!
I did some explorations into how dark mode could look a while back. These aren’t complete, but gives an idea of the direction we were headed.
RToz6tIuQ7nlZrikBte4GU-fi-4369_162098
The most important thing is to implement this in a way that’s easy to maintain and scalable if we want to add other themes in the future (high contrast, custom user themes, etc.).
I agree with @youknowriad that we need to create a set of CSS variables that define a theme, and then use those to set colors for each component within the app. Ideally this integrates with theming in @wordpress/components once that's in place.
Thanks for jumping in and putting together this proposal, @matt-west! 🙌 @draganescu, what’s the best way for design to stay ahead of these issues? I’ve added the |
@matt-west @crisbusquets thanks for lending a hand. This is a draft PR I did exclusively by spending tokens - Riad looped you in, which is good, I'd have done it once the PR was not a draft anymore. PRs don't have to land - e.g. in this one what interests me is the feature mechanism but there is a lot of cleanup to do. |
Playful attempt at adding #553
Summary
options
Details
This PR implements a comprehensive dark mode solution for the WordPress Studio application:
New Features
UI Enhancements
Technical Implementation
Accessibility
Technical Details
The implementation uses Tailwind's dark mode with the 'class' strategy, applying a 'dark'
class to the root element when dark mode is active. For elements that may be appended to the
document body (like modals), we've implemented both .dark and body.dark selectors to ensure
consistent styling.
Theme preference is stored in the app's user preferences system via IPC calls to ensure
persistence across sessions.
Testing
Screenshots