[VW-0] Dark Mode Fixes for Workflow Editor, Asset / Vuln Dashboard#139
Conversation
|
The latest updates on your projects. Learn more about Vercel for GitHub. 2 Skipped Deployments
|
📝 WalkthroughWalkthroughThis PR updates three UI components across the application with dark-mode and semantic theming support. Badge destructive styling switches to semantic design tokens. Editor configures React Flow UI with theme-aware colors and styles derived from ChangesTheme-aware styling enhancements
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~20 minutes Suggested reviewers
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Nitpick comments (1)
src/features/editor/components/editor.tsx (1)
43-48: 💤 Low valueConsider consistent color approach for light and dark modes.
Light mode uses a hardcoded RGB color
rgb(100 116 139 / 0.55)for background dots while dark mode uses the CSS variablevar(--border). While the comment mentions this is a workaround, this inconsistency could make theme maintenance harder.Consider defining a CSS variable for the light mode dot color as well, or document why the hardcoded value is necessary for light mode visibility.
♻️ Alternative approach using CSS variables
If your theme system supports it, define semantic variables:
const backgroundDotColor = - colorMode === "dark" ? "var(--border)" : "rgb(100 116 139 / 0.55)"; + colorMode === "dark" ? "var(--border)" : "var(--border-light, rgb(100 116 139 / 0.55))";This allows theme-level control while keeping the fallback.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@src/features/editor/components/editor.tsx` around lines 43 - 48, The backgroundDotColor uses a hardcoded RGB for light mode while dark mode uses var(--border); change backgroundDotColor to read a semantic CSS variable (e.g., var(--background-dot, rgb(100 116 139 / 0.55))) and update the comment to explain the fallback, so both colorMode branches reference a CSS variable for consistency (adjust miniMapMaskColor only if needed) and ensure the variable name aligns with your theme tokens; if a theme variable cannot be added, explicitly document in the comment why the hardcoded RGB is required.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@src/features/editor/components/editor.tsx`:
- Around line 39-42: resolvedTheme from useTheme can be undefined on initial
render causing colorMode to default to "light" incorrectly; update the logic
around resolvedTheme in the component (where useTheme(), resolvedTheme,
setEditor and editorAtom are used and colorMode is computed) to explicitly
handle undefined by using a fallback (e.g., use theme || 'system' or check
resolvedTheme !== undefined before deriving colorMode) or delay setting the
editor state until resolvedTheme is available (e.g., guard in an effect or
conditional render) so dark-mode users don't see a flash and the editorAtom
receives the correct "dark" or "light" value.
---
Nitpick comments:
In `@src/features/editor/components/editor.tsx`:
- Around line 43-48: The backgroundDotColor uses a hardcoded RGB for light mode
while dark mode uses var(--border); change backgroundDotColor to read a semantic
CSS variable (e.g., var(--background-dot, rgb(100 116 139 / 0.55))) and update
the comment to explain the fallback, so both colorMode branches reference a CSS
variable for consistency (adjust miniMapMaskColor only if needed) and ensure the
variable name aligns with your theme tokens; if a theme variable cannot be
added, explicitly document in the comment why the hardcoded RGB is required.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: 73f54cac-4356-4d8d-9da7-459f20e933a9
📒 Files selected for processing (3)
src/components/ui/badge.tsxsrc/features/editor/components/editor.tsxsrc/features/vulnerabilities/components/vulnerabilities.tsx
| const { resolvedTheme } = useTheme(); | ||
|
|
||
| const setEditor = useSetAtom(editorAtom); | ||
| const colorMode = resolvedTheme === "dark" ? "dark" : "light"; |
There was a problem hiding this comment.
Handle undefined resolvedTheme during initial render.
resolvedTheme from next-themes can be undefined during the initial render before the theme is resolved, which will default colorMode to "light". This may cause a brief flash or incorrect initial rendering in dark mode.
Consider using theme with a fallback or handling the undefined case explicitly:
💡 Proposed fix to handle undefined theme
- const { resolvedTheme } = useTheme();
+ const { resolvedTheme = "light" } = useTheme();Or handle it more explicitly:
const { resolvedTheme } = useTheme();
- const colorMode = resolvedTheme === "dark" ? "dark" : "light";
+ const colorMode = resolvedTheme === "dark" ? "dark" : resolvedTheme === "light" ? "light" : "light";Alternatively, consider using the theme prop with system as a fallback if you want to respect system preferences during the initial render.
📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| const { resolvedTheme } = useTheme(); | |
| const setEditor = useSetAtom(editorAtom); | |
| const colorMode = resolvedTheme === "dark" ? "dark" : "light"; | |
| const { resolvedTheme = "light" } = useTheme(); | |
| const setEditor = useSetAtom(editorAtom); | |
| const colorMode = resolvedTheme === "dark" ? "dark" : "light"; |
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@src/features/editor/components/editor.tsx` around lines 39 - 42,
resolvedTheme from useTheme can be undefined on initial render causing colorMode
to default to "light" incorrectly; update the logic around resolvedTheme in the
component (where useTheme(), resolvedTheme, setEditor and editorAtom are used
and colorMode is computed) to explicitly handle undefined by using a fallback
(e.g., use theme || 'system' or check resolvedTheme !== undefined before
deriving colorMode) or delay setting the editor state until resolvedTheme is
available (e.g., guard in an effect or conditional render) so dark-mode users
don't see a flash and the editorAtom receives the correct "dark" or "light"
value.
2 participants
Minor UI fixes for dark mode components, particularly in the Workflow Editor, Asset Dashboard and Vulnerability Dashboard
Workflow Editor
Before
After
Background, controls and minimap are the main changes. Background turned charcoal grey as that's the default react-flow color, can make it more in line with other colors if needed
Asset Dashboard
Remediation Badges are the main change
Vulnerability Dashboard
Badges & Alert Banner are the main changes here
Summary by CodeRabbit