Allow defining multiple adpative themes

[shahzaib78631]

Feature Request: Support for Multiple Adaptive Themes

I’d like to request a feature for Unistyles to allow defining multiple adaptive themes within the library. This would enable developers to configure theme groups, each containing light and dark variants.

Example configuration:

themes: {
'default-light': Theme,
'default-dark': Theme,
'premium-light': Theme,
'premium-dark': theme
},
useAdaptiveTheme: true,
adaptiveThemes: {  
  default: {  
    light: Theme,  
    dark: Theme  
  },  
  premium: {  
    light: Theme,  
    dark: Theme  
  }  
}

[jpudysz]

Hey, thank you for the idea.

I think it's super custom case and most of the users don't need multiple light and dark themes. Nevertheless it's still possible to have such API with the current state.

By default set your "default" themes as light and dark. If user want premium dark and light themes simply update themes with new colors:

https://www.unistyl.es/v3/guides/theming#update-theme-during-runtime

To save this preference keep this info somewhere in the storage and override them on each launch.

[axyz]

@jpudysz hi, I have a similar use case, but even more complex.

Multiple themes each one also defining multiple color schemes beyond just light and dark.

For example:
Default theme + light scheme
Default theme + dark scheme
Default theme + monochrome scheme
Default theme + high contrast scheme
Premium theme + light scheme
Premium theme + dark scheme
Premium theme + monochrome scheme
Premium theme + high contrast scheme
Etc...

Additionally different views might have a scoped theme + scheme combination (e.g show a monochrome or dark block within a light screen)

I'm thinking how this could be modeled using the runtime API.

If I understand correctly, it is mandatory to give up the adaptive themes in order to enable them via the API at runtime?

Naively, there could be different react context providers for themes and schemes taking care of returning a scoped theme plus calling the runtime on each rerender if the context has changed in order to tweak the colors based on some config.

Would that be possible? I'm mostly worried of losing the many performance benefits of the library.

Do you have any other recommendation or alternative solution?

Assuming no adaptive themes, is there something similar to scoped themes, but for color schemes?

Thanks

[jpudysz]

You can achieve this easier with listener. With beta.5 you can now listen to colorScheme changes:

1. Disable adaptiveThemes
2. Create listener

const ThemeSwitcher: React.FunctionComponent<ThemeSwitcherProps> = ({ initialTheme }) => {
   const { rt } = useUnistyles()

   useEffect(() => {
      // eg.
      if (rt.colorScheme === ... && rt.themName ===...) {
          UnistylesRuntime.setTheme(...)
      }
      
   }, [rt.colorScheme, rt.themeName])

   return null
}

Put it somewhere in the App and you should be good to go.

[axyz]

Interesting. I assume this would also work for scoped themes right? Because the runtime can update the theme definition globally based on the scheme for example?

But how can I then change the color scheme, either globally or in the scope of a given view (similar to what is possible with scoped themes for themes)? Wouldn't setTheme in that case also affect possible "sibling scopes"?

[jpudysz]

Scoped themes are fixed to the given style. If you want to change the "fixed style" you need to update the prop of the component (ScopedTheme).

You can also create own Provider, with the listener from above and pass it as a prop to the ScopedTheme.
This should work as using context in your component will re-render it.

This is not ideal, but you have a custom case and it requires custom data flow.

[axyz]

Trying to understand how much that might impact on performance.

I have some doubts on that:

• when the context changes the theme, only the stylesheets that have a dependency on theme will be updated? Or it will recalculate all of them even if static or depending on rt? I guess React will still rerender the subtree due to context change, but that might be cheap if the context is used only in the scoped theme component. Not sure, though, what happens in the native modules holding the stylesheet references.
• Is it correct that there might be some performance disadvantage only when changing theme or color schemes? Would this solution still ensure no rerenders in case of updates in the mini runtime or other dependencies?
• does the dependency tracking check for specific fields in the theme? e.g. changing a color scheme would result in only updating components that use theme.color.* ? And would this still hold true with the custom provider approach?

[jpudysz]

when the context changes the theme, only the stylesheets that have a dependency on theme will be updated?

Correct

Or it will recalculate all of them even if static or depending on rt

Statics are processed only once. StyleSheets with rt also depends on theme.

Is it correct that there might be some performance disadvantage only when changing theme or color schemes

Correct, only then. Also if you don't use adaptiveTheme: true color scheme change is ignored and StyleSheets are not recomputed.

Would this solution still ensure no rerenders in case of updates in the mini runtime or other dependencies

Unistyles computes your styles once. Re-render simply updates the values.

does the dependency tracking check for specific fields in the theme

No, themes in C++ are not parsed. I'm simply keeping pointer to your JS theme. I'm not aware about your theme structure.