I have a problem i need an advice on. I used to ha...

# compose

[myanmarking]

I have a problem i need an advice on. I used to have brand colors like R.brand.blue that had two variantes, for light and dark mode. The resource system resolved them. With compose, i create brand colors like

val MaterialTheme.brandColor: BrandColor
    @Composable
    @ReadOnlyComposable
    get() = LocalBrandColor.current

and injected into the theme with CompositionLocalProvider. So in a composable, i can do MaterialTheme.brandColor.blue and it will resolve for light and dark. My problem: I used to resolve this colors in the viewMode, like using R.brand.blue and it was fine. In compose, i cannot do that, because it required a composable context. What can i do ?

[myanmarking]

hm. i guess i managed to solve the problem using an enum and a converted

[mattinger]

TO be honest, i create an entirely new theme that sort of mimics what MaterialTheme does, but has a different set of semantic keys (theme attributes). I then have that theme set the MaterialTheme the way i want it for fallback behavior. I tried to do what you are suggesting at first, but I found the use of extension properties on MaterialTheme very misleading when i looked at it from the point of view of someone who didn’t write it.

[mattinger]

I wanted a clear distinction of what was in our theme and what as in the material theme.

[Colton Idle]

Hm. I could be wrong. but what you're doing seems wrong? that does not seem like the correct way to add a custom color system.

If you are using colors that don't exist in the material theme color system, you should follow what the compose sample "jetsnack" does.

Jetsnack's major feature is demonstrating how to implement a custom design system. Jetsnack has a bespoke color system and does not use Material color theming.

I base all of my compose apps color systems based on this code: https://github.com/android/compose-samples/tree/main/Jetsnack