[REACT] Best practice for switching between light and dark themes at runtime?

[jimmycallin]

Hi all,

I'm looking for the recommended way to support runtime light/dark theme switching with the Stockholm theme, and I'd like to sanity-check the approach before committing to it long-term.

@bryntum/<pkg>/stockholm-dark.css and stockholm-light.css both declare their variables on :root. That makes them mutually exclusive by construction — whichever sheet is imported (or imported
last) wins for the whole document. Our app has a user-controlled theme toggle, so we need both variants to coexist in the same page and switch based on a class or attribute on <html>.

What I've tried

1. Statically import only one variant. Works, but obviously can't switch at runtime without a full reload.

2. Dynamically swap <link> tags / toggle disabled. Functional, but causes a visible flash on switch and ships both stylesheets to every user regardless of which theme they start with. Also
   brittle around StyleSheet ordering vs. our own CSS.

3. Build-time rewrite of :root → html[data-theme="dark"] / html[data-theme="light"]. This is what we currently do — a small script copies both sheets and rewrites the top-level selector so they
   can be imported together and switched via an attribute on <html>. It works, but but feels brittle in the long-term.

   
   

   Is there an officially supported way to have both Stockholm variants live in the same document and toggle between them via a class/attribute? Or is rewriting :root genuinely the intended path
   for apps with a manual light/dark toggle?

   
   

   If there isn't a built-in way today, would you consider shipping a "scoped" variant of the theme sheets — e.g. stockholm-dark.scoped.css where the top-level selector is
   [data-bryntum-theme="dark"] instead of :root — so both can be imported side-by-side without any post-processing? That seems like a small, additive change that would cover this use case cleanly.

Thanks!

[amurashin]

Bryntum customer here

We've created a custom theme where we redefined all colours using CSS light-dark() function and overridden --b-widget-color-scheme: inherit.

This way theme toggling is done by simply setting the root color-scheme property: light, dark, or light dark ("auto", uses OS default).

I hope this helps!

[mats]

@jimmycallin Johan will add some wisdom here soon.

@amurashin - Thanks for chiming in! Curious if you see any performance hit when using light-dark() across the whole app? We're likely moving towards using it as well soon.

[amurashin]

We have not observed any CSS-related performance dips with this approach, most of our performance issues are caused by Lightning Web Security

Salesforce is using light-dark() in the Lightning Design System v2, we simply use their CSS properties (dubbed "styling hooks") to override Bryntum structural stylesheet values. This allows us to match current theme accents and the colour scheme of the Salesforce org.

Screen Recording 2026-04-30 at 16.07.00.gif (1.73 MiB) Viewed 7306 times

[johan.isaksson]

Hi,

Currently the only officially supported way of switching between light and dark is replacing the links. This is what we do in our demos when you click the light / dark toggle (we call DomHelper.toggleLightDarkTheme()). It will not flicker if you wait for the new theme to load before removing the old.

light-dark() was not widely available when work on the new themes started, if we were to start over now it would likely have been used. With the new themes still being kind of new, I don't think we want to upset things by replacing them just yet. But we could introduce a new "automatic" version of each theme and set an eol for the others. Eg. svalbard-light.css, svalbard-dark.css & svalbard.css (< automatic). We will consider that for our next major, ticket to track here: https://github.com/bryntum/support/issues/13107

Technically it should be really easy. Only worry I have is that it will impact performance, transitioning to CSS had some impact and if each color is also basically a conditional it might be noticeable. But if the hit is low, it seems worth the tradeoff to me.