question for those who use some Material composables in their apps, yet have a fully customised colo...

# compose

[james]

question for those who use some Material composables in their apps, yet have a fully customised colour system which does not override MaterialTheme in any way, nor share its naming system: how do you handle certain Material composables which hardcode colours and do not provide a way to override them?

the only way I can think of to do this is to create a MaterialTheme and try my best to match my design system colours to the Material ones (Primary, OnPrimary, Surface, OnSurface etc).. then when I need to use a certain Material composable that doesn’t allow me to override the colour I can use CompositionLocalProvider to wrap that particular composable

☝️ this seems like it would work, but I wonder if there’s a cleaner way to achieve this?

[Colton Idle]

This is what I do. I wish there was a better way... but maybe this is the best way? I create alternate themes when I need some other primary color or something temporarily. But yeah. It's not great. There's like 5 droidcon talks in the past 3 months regarding design systems that are worth taking a look at.

[Zoltan Demant]

Just curious, which composables have you found to not allow customizing colors via parameters? I havent noticed any thus far!

[K Merle]

Is it hard to override MaterialTheme? Never tried.

[Zoltan Demant]

@K Merle Theres a good article about it here 🙂

[james]

thanks for the answers! 🙏

the one I was having some issues with was DropdownMenu

I’ve now created an extension function inside Theme.kt which is like:
fun MyTheme.toMaterial3ColorScheme(darkMode: Boolean)

I suppose I should have done this all along, but I was trying to get away with not having to maintain (or sit down and think about 😅) a mapping for my theme <-> material theme