Problem
When a user changes the theme preference (e.g. Dark → Light) on the main page, sub-pages opened via navigate() / open() don't reflect the change. They either:
- Use the system default (if no
force_theme_style is passed)
- Stay stuck on whatever
force_theme_style was hardcoded at navigation time
Why it happens
Each sub-page is a separate LynxView container with its own JS runtime. There's no shared state between containers. The theme for each container is determined at creation time:
force_theme_style scheme parameter → highest priority
- System dark mode setting → fallback
- Default (light) → last resort
There is no mechanism to:
- Persist a user's in-app theme preference at the native level
- Inject a persisted preference into new containers automatically
- Broadcast theme changes to already-running containers
Current workaround
The frontend can pass force_theme_style explicitly when navigating:
navigate({
path: 'settings.lynx.bundle',
options: {
params: { force_theme_style: currentTheme }
}
})
But this is fragile — every navigation call must know the current preference, and it doesn't handle the case where a user changes theme while a sub-page is already open.
Ideal upstream solution
The Sparkling SDK should handle theme sync at the container level:
- Persist theme preference natively: Add a pipe method (e.g.
sparkling.setThemePreference) that saves the preference to UserDefaults / SharedPreferences
- Inject into new containers: In
SPKGlobalPropsUtils.defaultGlobalProps() (iOS) and GlobalPropsUtils.builtInStableFields (Android), read the persisted preference and set preferredTheme in globalProps automatically
- Broadcast to active containers: When preference changes, call
updateGlobalProps on all active SPKWrapperLynxView / SimpleLynxKitView instances so already-open pages react
This way theme syncs across all containers without the frontend needing to pass force_theme_style everywhere.
Affected code
- iOS:
SPKGlobalPropsUtils.defaultGlobalProps(), SPKLynxKitUtils.globalProps()
- Android:
GlobalPropsUtils.builtInStableFields, HybridContext.getTheme()
- Frontend:
ThemeProvider reads lynx.__globalProps.preferredTheme at init — this value is currently only set via force_theme_style
Labels
Bug, enhancement, SDK
Problem
When a user changes the theme preference (e.g. Dark → Light) on the main page, sub-pages opened via
navigate()/open()don't reflect the change. They either:force_theme_styleis passed)force_theme_stylewas hardcoded at navigation timeWhy it happens
Each sub-page is a separate LynxView container with its own JS runtime. There's no shared state between containers. The theme for each container is determined at creation time:
force_theme_stylescheme parameter → highest priorityThere is no mechanism to:
Current workaround
The frontend can pass
force_theme_styleexplicitly when navigating:But this is fragile — every navigation call must know the current preference, and it doesn't handle the case where a user changes theme while a sub-page is already open.
Ideal upstream solution
The Sparkling SDK should handle theme sync at the container level:
sparkling.setThemePreference) that saves the preference to UserDefaults / SharedPreferencesSPKGlobalPropsUtils.defaultGlobalProps()(iOS) andGlobalPropsUtils.builtInStableFields(Android), read the persisted preference and setpreferredThemein globalProps automaticallyupdateGlobalPropson all activeSPKWrapperLynxView/SimpleLynxKitViewinstances so already-open pages reactThis way theme syncs across all containers without the frontend needing to pass
force_theme_styleeverywhere.Affected code
SPKGlobalPropsUtils.defaultGlobalProps(),SPKLynxKitUtils.globalProps()GlobalPropsUtils.builtInStableFields,HybridContext.getTheme()ThemeProviderreadslynx.__globalProps.preferredThemeat init — this value is currently only set viaforce_theme_styleLabels
Bug, enhancement, SDK