fix: enhance dark theme support for Visualizer and DocsLayout components#5507
Conversation
📝 WalkthroughWalkthroughAdds dark-mode support: a TypeScript CSS module declaration, minor component class updates to opt into the stylesheet, and extensive dark-theme CSS for the schema visualizer and explorer menu. ChangesDark Mode Styling for Schema Visualizer and Explorer Layout
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~25 minutes Suggested reviewers
Poem
🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Warning There were issues while running some tools. Please review the errors and either fix the tool's configuration or disable the tool if it's a critical failure. 🔧 ESLint
ESLint install failed: dependency version conflict. Check your lock file or package.json. 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 |
✅ Deploy Preview for asyncapi-website ready!Built without sensitive environment variables
To edit notification comments on pull requests, go to your Netlify project configuration. |
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## website-ui #5507 +/- ##
============================================
Coverage 100.00% 100.00%
============================================
Files 23 23
Lines 931 931
Branches 180 180
============================================
Hits 931 931 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
b7cc983 to
6d87dca
Compare
|
@CodeRabbit Review |
✅ Actions performedReview triggered.
|
|
Actionable comments posted: 0 |
@princerajpoot20 what is your idea. because light theme we have some diffrence. |
princerajpoot20
left a comment
There was a problem hiding this comment.
#5507 (comment) Good point @sammy200-ui
@hasithasandunlakshan can you please have a look at this. the black is not going well with the theme
Hey in light theme we have not same styles in home page and this page
- Explorer json view
|
@princerajpoot20 @sammy200-ui what do you think ? Should we change light theme as well ? |
Hi @princerajpoot20 I feel this is good for dark theme.If we use home page colors we should change background colors as well. |
| @@ -0,0 +1 @@ | |||
| declare module 'schyma/dist/esm/style.css'; | |||
There was a problem hiding this comment.
@hasithasandunlakshan
what is the purpose this file solves?
There was a problem hiding this comment.
- Baiscally it resolves typescript errors.If we remove this it gives
Cannot find module 'schyma/dist/esm/style.css' or its corresponding type declarations.
The issue is in Visualizer.tsx is import schyma/dist/esm/style.css. But since visualizer.tsx is type script file it expects css file as a typescript file.
Adding this type declare it is fixing above issue.
There was a problem hiding this comment.
@hasithasandunlakshan what is the purpose this file solves?
- Baiscally it resolves typescript errors.If we remove this it gives
Cannot find module 'schyma/dist/esm/style.css' or its corresponding type declarations.
The issue is in Visualizer.tsx is import schyma/dist/esm/style.css. But since visualizer.tsx is type script file it expects css file as a typescript file.
Adding this type declare it is fixing above issue.
523508d to
6660517
Compare
|
|
@coderabbitai full review once again |
|
✅ Actions performedFull review triggered. |
There was a problem hiding this comment.
🧹 Nitpick comments (2)
styles/globals.css (2)
437-461: 💤 Low valueConsider the maintenance risk of tightly coupled selectors.
These selectors (e.g.,
.dark .schema-visualizer .panel,.dark .schema-visualizer .custom-node) are tightly coupled to the internal DOM structure and class names generated by the Schyma library. If Schyma updates its component structure or class naming in a future release, these styles may break silently.While this approach works for the current version, consider requesting or contributing CSS custom properties (CSS variables) to the Schyma library for theming. This would provide a more stable API for customization that isn't tied to internal implementation details.
🤖 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 `@styles/globals.css` around lines 437 - 461, These deeply nested selectors (.dark .schema-visualizer .panel, .dark .schema-visualizer .custom-node, .react-flow__node-*, etc.) couple the theme to Schyma's internal DOM; instead, define a small set of CSS custom properties on the component root (.schema-visualizer and .dark .schema-visualizer) such as --sv-bg, --sv-color, --sv-panel-bg, --sv-border-color and use those variables in your existing internal rules (or prefer only single-level selectors referencing the root vars); if Schyma supports or can be extended to expose theme variables, migrate to those library-provided vars and remove deep class-specific overrides to reduce fragility when Schyma changes.
522-565: ⚖️ Poor tradeoffFragile color overrides using
!importantand inline style selectors.The use of
!importantflags (lines 528-529, 535-536, 540-564) and attribute selectors targeting inline styles (lines 543-545, 551-553) suggests that the Schyma library applies inline styles with high specificity. This approach works but is fragile:
!importantproliferation makes future style adjustments harder and creates specificity wars- Inline style attribute selectors like
span[style*="color: rgb(153, 0, 85)"]will break if the library:
- Changes the RGB values
- Uses hex, hsl, or CSS custom properties instead
- Applies colors differently
If Schyma exposes theming hooks or CSS custom properties, migrate to those. Otherwise, document this brittleness and monitor for Schyma updates that might change color application.
🤖 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 `@styles/globals.css` around lines 522 - 565, The overrides under .dark .schema-visualizer .examples-code-container are fragile because they rely on !important and fragile attribute selectors (e.g., span[style*="color: rgb(153, 0, 85)"])—replace them by using the library’s theming hooks or CSS custom properties where possible (map the colors to variables like --sv-bg, --sv-text, --sv-keyword and consume those in .schema-visualizer rules), remove !important once variables/hooks are applied, and instead increase selector specificity only if needed (e.g., scope under .schema-visualizer and targeted token classes: .token, .token.property, .token.string, .token.operator, .token.number, .token.boolean, .token.null). If Schyma/theming hooks aren’t available, add a short inline comment documenting the brittleness and use safer selectors (avoid exact inline style matching; prefer token class names) and centralize the override colors into CSS variables so future changes are easier to update.
🤖 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.
Nitpick comments:
In `@styles/globals.css`:
- Around line 437-461: These deeply nested selectors (.dark .schema-visualizer
.panel, .dark .schema-visualizer .custom-node, .react-flow__node-*, etc.) couple
the theme to Schyma's internal DOM; instead, define a small set of CSS custom
properties on the component root (.schema-visualizer and .dark
.schema-visualizer) such as --sv-bg, --sv-color, --sv-panel-bg,
--sv-border-color and use those variables in your existing internal rules (or
prefer only single-level selectors referencing the root vars); if Schyma
supports or can be extended to expose theme variables, migrate to those
library-provided vars and remove deep class-specific overrides to reduce
fragility when Schyma changes.
- Around line 522-565: The overrides under .dark .schema-visualizer
.examples-code-container are fragile because they rely on !important and fragile
attribute selectors (e.g., span[style*="color: rgb(153, 0, 85)"])—replace them
by using the library’s theming hooks or CSS custom properties where possible
(map the colors to variables like --sv-bg, --sv-text, --sv-keyword and consume
those in .schema-visualizer rules), remove !important once variables/hooks are
applied, and instead increase selector specificity only if needed (e.g., scope
under .schema-visualizer and targeted token classes: .token, .token.property,
.token.string, .token.operator, .token.number, .token.boolean, .token.null). If
Schyma/theming hooks aren’t available, add a short inline comment documenting
the brittleness and use safer selectors (avoid exact inline style matching;
prefer token class names) and centralize the override colors into CSS variables
so future changes are easier to update.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
Run ID: 2903588b-75ac-4cac-b794-fa2abd9cd898
📒 Files selected for processing (4)
components/docs/Visualizer.tsxcomponents/layout/DocsLayout.tsxstyles/globals.csstypes/packages/css.d.ts
















Description
/docs/reference/specification/v3.1.0-explorer.schyma/dist/esm/style.css.Reproduction Guidelines
Test in light theme:
Switch to dark theme.
Test in dark theme:
Screenshots
Light Theme Comparison
Dark Theme Comparison
Summary by CodeRabbit