Skip to content

feat(lib-vuetify): system theme option and theme-switcher improvements#34

Open
BatLeDev wants to merge 3 commits into
mainfrom
feat-theme-switcher
Open

feat(lib-vuetify): system theme option and theme-switcher improvements#34
BatLeDev wants to merge 3 commits into
mainfrom
feat-theme-switcher

Conversation

@BatLeDev
Copy link
Copy Markdown
Member

@BatLeDev BatLeDev commented May 22, 2026

Add a system theme option to the theme-switcher and let host apps supply their own theme offers.

What changed:

  • Add a system theme that follows the OS prefers-color-scheme / forced-colors, and treat an absent theme cookie as implicit system.
  • Export resolveTheme (replacing the private getDefaultTheme) plus the Theme / AppliedTheme / ThemeOffers / FullSiteInfo types, so consumers can resolve a stored preference to a concrete theme. Vuetify's defaultTheme now uses the resolved name (its built-in 'system' would otherwise bypass custom themes).
  • Re-resolve the applied theme live when the OS preference changes while on system.
  • Add an optional theme prop to the switcher so hosts that don't expose config via session.fullSite (e.g. the Nuxt portal) can drive which options are shown.
  • Guard window.matchMedia access for SSR; capitalize the i18n labels.

Why: improve the theme-switcher so users can defer to their OS preference, and so hosts with their own theme config can reuse the component.

Regression risks:

  • session.theme.value now defaults to 'system' (was null) and is no longer mutated to a concrete theme on site load. Consumers reading it to know the applied theme, or checking == null for "no choice", must use resolveTheme(session.theme.value, fullSite) instead.
  • FullSiteInfo.theme.dark/hc/hcDark are now optional (interface is now exported); downstream code assigning them to a strict boolean may need a ?? false.
  • vuetifySessionOptions forces defaultTheme: 'default' when fullSite is unset, instead of echoing session.theme.value — low impact, but a behavior change.

BatLeDev added 3 commits June 5, 2026 16:14
Theme switcher options (default, dark, high contrast, dark and high contrast)
now start with a capital letter in both locales.
Previously the OS theme preference (prefers-color-scheme, forced-colors) was
only consulted once on the very first visit; after that the resolved value was
locked in the `theme` cookie and never re-evaluated. On mobile devices that
toggle light/dark over the day, the chosen theme could not follow the OS.

- Add `'system'` to the `Theme` union and store it explicitly in the cookie.
- New `resolveTheme()` helper derives the effective theme via `getDefaultTheme`
  when the user is on 'system' (or when the cookie is absent, which is now
  treated as an implicit 'system' choice).
- Listen to `prefers-color-scheme` and `forced-colors` matchMedia changes and
  re-apply the theme reactively while the user is on 'system' — no reload.
- Expose a 'system' radio option in the theme-switcher (i18n: Système / System).

simple-directory does not read the theme cookie server-side (verified across
its api/ and ui/ sources) and reuses lib-vuetify's theme-switcher directly, so
the new cookie value is transparently handled there too.
@BatLeDev BatLeDev force-pushed the feat-theme-switcher branch from 87060e8 to 67c0688 Compare June 5, 2026 17:08
@BatLeDev BatLeDev marked this pull request as ready for review June 5, 2026 17:16
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant