Dynamic theme change in Semantic-UI

Question

There are many questions asking how to change the theme in Semantic-UI, but I have not been able to find even a question where it refers to changing the theme dynamically, i.e. after a webpack build.

I want to allow each user of a site to save their own preference for the theme. I have some users who prefer dark themes, and others who are color-blind, and others who have weak eyes and need larger fonts, or more contrast, etc.

I know it's possible to change the theme dynamically since the semantic-ui demos all do it. Unfortunately, the Theming page and all documentation I have seen describes how to change the site-wide theme, and apply that, in a new site-wide build. Or to customize that (still) site-wide build.

I think I'd be happy to just be able to add a class to the class list for an element (e.g. "github") and have it use that theme for that user (even if it was just for that element). But ideally, I'd like to have my page load an extra .less or .css file(s) with site-wide overrides for that user, for the user-selected theme.

I'm still pretty new semantic-ui and to applying dynamic changes to a webpack site. Any suggestions for how to apply additional less variable changes after build, or to reload entire Semantic-UI themes, like the demo does?

Note that demo site is not a link to GitHub; it's a look-alike with a paint can icon near the top-right which brings up a sidebar that allows you to change themes. Dynamically.

Update:

I need to test this now, but I may have an answer for my own question here.

It seems that the gulp build process typically compiles and combines all the less and other files into the dist folder as semantic.css, semantic.js, semantic.min.css and semantic.min.js. It also produces different individual component .css files in the dist/components subfolder, but (I think) if you're loading the full css file (e.g. semantic.min.css), that you don't really need the components subfolder. That this is present for those sites who want to optimize to the point of only including the .css files for the components they use?

So it's already processed and combined, and to swap themes, I think all that is necessary is to swap one semantic.min.css file with the output of the build for another theme. The .js files are the same, at least for default vs github themes.

If this is true, it's a matter of copying the semantic.min.css to an alternative file, for example, semantic.github.min.css and use that .css file instead. Or copy it to a theme subfolder like github/semantic.min.css. Then, in either case, update the DOM with a new href on the stylesheet originally referenced.

Summary: It looks like it's all in the semantic*.css file and swapping the output of different builds allows us to swap themes. I'll test this later tonight.

Update 2:

I updated the theme.config file with all github entries, then rebuilt the dist folder, copied the semantic.min.css as semantic-github.min.css to my static folder with the original, then just updated the href to select it:

// normally:    <link rel="stylesheet" type="text/css" href="/static/semantic/semantic.min.css">
// non-default: <link rel="stylesheet" type="text/css" href="/static/semantic/semantic-theme.min.css">
function swapThemeCss (theme) {
  console.log('Theme change to "' + theme + '".')
  let sheet = document.querySelector('#theme')
  if (!sheet) {
    return
  }

  if (theme === 'default') {
    sheet.setAttribute('href', '/static/semantic/semantic.min.css')
  } else {
    sheet.setAttribute('href', '/static/semantic/semantic-' + theme + '.min.css')
  }
}

Oh also, in the example above, I gave the link an id of 'theme' to make it easier to find it and replace the href dynamically:

<link id="theme" rel="stylesheet" type="text/css" href="/static/semantic/semantic.min.css">

Answer 1

"So it's already processed and combined, and to swap themes, I think all that is necessary is to swap one semantic.min.css file with the output of the build for another theme."

Correct.

Depending on whether you're having per-user styles, or just multiple themes the user can pick from, you can simply have separate less files with per-theme overrides that can be compiled with webpack but perhaps not inserted into your index.html. Then you can dynamically add/remove the <link>s to depending on the user preference. The dynamic adding will cause a flicker from the default styles to the per-user theme styles if you're inserting the <link> tags via frontend javascript (because it must wait for the frontend JS to load, which will render the page/default styles in the meantime, then inject the new <link> and only show the new styles once those have been loaded). Add the per-user <link> tags serverside to make it seamless.