Dark Theme Support in @frontapp/ui-kit

Hi there!

We don’t currently have a plan to offer a dark mode or any standardized design options for Front plugins using our UI kit, though we do have a feature request for this that I highly suggest you add your vote to here: https://front.ideas.aha.io/ideas/PRD-I-4187.

My apologies for any inconvenience this may cause you, but let me know if you have any other questions!

Hi,

Thanks for the clarification and for sharing the feature request link - I’ve added my vote 

Just to confirm my understanding: should we assume that dark mode support for @frontapp/ui-kit is unlikely to be introduced within the next year?

The reason I’m asking is that our agents are actively requesting dark theme support in our plugin, so we’re currently evaluating possible workarounds.

At the moment, the only way we’ve found to implement dark mode is by overriding UI Kit styles manually. For example:

.tabsTheme > div > div:has(span[style*="opacity: 0.3"]) {

color: var(--tab-text) !important;

}

.tabsTheme > div > div:not(:has(span[style*="opacity: 0.3"])) {

color: var(--tab-text-active) !important;

}

.tabsTheme > div > div:not(:has(span[style*="opacity: 0.3"])) > div:last-child {

background: var(--tab-underline) !important;

}

.front-ui-kit-layer [data-popper-placement] > div > div {

background: var(--dd-bg) !important;

}

.front-ui-kit-layer [data-popper-placement] *:is([role="option"], [role="menuitem"]):hover {

background: var(--dd-hover) !important;

}

.projectSelectTheme .front-hover-parent > div > div {

color: var(--select-text) !important;

}

.projectSelectTheme .front-hover-parent:hover {

background: var(--select-hover) !important;

}

This approach technically works, but it feels fragile. If the UI Kit updates internal class names, structure, or styles, we may need to refactor these overrides again.

So my main question is:

• Is overriding component styles currently the recommended approach for implementing dark mode in plugins?
• Or is there any safer pattern we should follow to reduce the risk of breaking changes?

We completely understand that theming may not be on the immediate roadmap, but we’d like to make sure we’re choosing the most stable possible solution.

Thanks again!

Thank you for voting on the feature request! In the meantime let me get back to you with regards to the best methods in accomplishing this!

Hi ​@gachi_dev,

Thanks for the detailed question and for sharing your approach! Let me clarify how to best handle this.

Current state: You're correct that the Front UI Kit component colors are hardcoded constants rather than CSS variables, and there's no theming layer at this time. Because of this, overriding styles is the appropriate approach for implementing dark mode in plugins right now.

Best practices for style overrides:

Here are some tips:

1. Prefer targeting component wrapper elements using CSS specificity rather than deeply nested internal elements. This reduces the chance of breaking changes.
2. Keep all overrides in a single stylesheet or module so they're easy to audit and update when upgrading UI Kit versions.
3. Subscribe to our release notes - we flag any breaking changes that might affect your overrides.

Your overrides should remain stable across version upgrades for the foreseeable future, and we'll communicate any structural changes that might impact them in our API-related release notes.

Looking ahead: While official dark mode support would require significant architectural changes and isn't currently prioritized, we appreciate you voting on the feature request. Your feedback helps us understand the demand.

Hope this helps! Let us know if you have any other questions.