Skip to content

feat(app): allow a host to inject theme and feature config#1442

Closed
SERDUN wants to merge 4 commits into
developfrom
feat/host-config-injection
Closed

feat(app): allow a host to inject theme and feature config#1442
SERDUN wants to merge 4 commits into
developfrom
feat/host-config-injection

Conversation

@SERDUN

@SERDUN SERDUN commented Jun 24, 2026

Copy link
Copy Markdown
Member

Overview

Lets an external host that mounts this app in-process — the theme configurator's realtime preview — supply the theme and feature config it should render, instead of the app's own bootstrap-built defaults.

This is the second of two PRs split out of the embedding work (the first, #1441, makes Firebase optional). The two are independent; the realtime preview consumes both.

Changes

  • main.dartRootApp gains optional themeSettings, themeMode and featureAccess parameters, provided down the tree:
    • FeatureAccess — a host-supplied value replaces the reactive StreamProvider; otherwise the stream is used as before.
    • ThemeSettings? / ThemeMode? — provided as nullable values (null in a normal run).
  • app.dart — when a non-null host theme is present, App pushes it into the AppBloc (AppThemeSettingsChanged / AppThemeModeChanged) in didChangeDependencies, so AppState stays the single source of truth for theme — no parallel override path, no streams smeared through the widget tree.

Verification

  • flutter analyze — clean.
  • All parameters are null in a standalone run; behaviour is unchanged.

SERDUN added 4 commits June 24, 2026 10:22
Add optional ThemeSettings, ThemeMode and FeatureAccess parameters to RootApp.
When a host (the theme configurator's realtime preview) mounts the app
in-process it supplies them; they are provided down the tree as plain values so
the app renders the host's config instead of its bootstrap-built defaults:

- FeatureAccess: a host-supplied value replaces the reactive StreamProvider.
- ThemeSettings / ThemeMode: provided as nullable values; App pushes a non-null
  host theme into the AppBloc (AppThemeSettingsChanged / AppThemeModeChanged) in
  didChangeDependencies, keeping AppState the single source of truth for theme.

All parameters are null in a normal standalone run, where behaviour is unchanged.
The realtime preview pushed the host theme mode through AppThemeModeChanged,
whose handler writes it into themeModeRepository (setThemeMode/clear). An
ephemeral preview therefore overwrote the device's saved theme-mode preference,
so the real app booted in the previewed mode afterwards.

Add a non-persisting AppThemeModePreviewed event that only emits the mode into
AppState, and dispatch it for host-supplied modes. Theme settings already used a
pure emit, so only the mode path needed this. The handler is synchronous and
registered without droppable(), so rapid preview toggles are no longer dropped.
Drop the separate themeMode injection parameter from RootApp. The app already
treats featureAccess.supportedConfig.themeMode as the authoritative theme mode
(build() derives finalThemeMode from it), and a host always supplies featureAccess,
so a parallel themeMode path was redundant.

It was also the only host-config path that persisted: it dispatched
AppThemeModeChanged, whose handler writes to themeModeRepository. The app runs
either standalone (config from local storage) or embedded in a host that provides
the config - never both - so this never corrupted a real preference, but routing
the mode through featureAccess keeps a single, non-persisting source for it.

Host theme settings still flow through AppThemeSettingsChanged (a pure emit).
@SERDUN

SERDUN commented Jun 24, 2026

Copy link
Copy Markdown
Member Author

Closing in favour of a cleaner approach: RootApp as the single injection boundary, everything below consuming via inherited providers (theme lifted out of the AppState render path).

@SERDUN SERDUN closed this Jun 24, 2026
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