We’re planning to use Material 3 for theming in ou...

# compose

[shivthepro]

We’re planning to use Material 3 for theming in our app, but we’re a bit confused about how deep we should go.

We’re considering the following approaches:
• Full Custom Theming → Wrapping all components in a design module (i.e., all shared components live here).
• Replacing Material Subsystem → The minimal changes Google suggests for overriding Material 3 behavior.
• Material 3 Theming → This seems fine for a new app, but for an existing app with a custom design system, it might not work well.
https://developer.android.com/develop/ui/compose/designsystems/custom

We’re quite late to adopting Compose, and we have a design system defined by our design team. We want all components to follow the customizations provided by them.

Our goal is to enforce usage of shared components from a central design module across the app. Allowing direct usage of Material 3 components in feature modules could lead to inconsistencies, so we’re looking to avoid that.

If you’ve tackled similar challenges or have recommendations on what works best in this scenario, we’d really appreciate your input. Thanks in advance! ✌️

[gildor]

We had the same conciderations a few years ago
We hide Material completely, it's the best approach in our experience, so devs could use only design system components and foundation (though some foundation also restricted by lint).
Also even if use Material 3 component under the hood, it's very nice to limit customisation too

[Trishiraj]

Here's the approach we've taken if you have a design system defined in place already.
1. Overriding the default colorSchemes of MaterialTheme would be a bad idea if you have colors, font styles and variables that cannot just be defined as primary, onPrimary etc as such.
So best would be,
1. Have an immutable data class for brandColors, throw all your custom color vals here (Now you don't need to have those material theme color scheme names, instead can use your own custom naming.
2. Then now you can easily assign colors by just defining them in the data class parameters yous made, so you can have brandColorsLight = BrandAppColors(define colors here). Same for dark mode.
3. Now create a call site object, i.e if you dont want to assign colors as "MaterialTheme.colorScheme.whatever"
4. Then write an object "CustomTheme { val colors: BrandAppColors = staticCompositionLocalOf { brandColorsLight }
5. Finally Provide this new colorScheme into your MaterialTheme { } method, Just make sure to wrap the content inside a CompositionLocalProvider(your colors and textstyles goes here)

[gildor]

Looks like a lot of steps just to create UI
With custom composables nothing to override, no option to misuse, just call it, get exactly result which you need with only options allowed by the design system

[Trishiraj]

Ya I dont think his question was about creating custom composables, Rather implement their custom design system without affecting the Material3 attributes of their custom composables?

[gildor]

Not sure that I understand your point.
I understand question well, and it about on which level do customization of UI if UI is based on Material 3

[gildor]

and my point that customize on each screen is a bad idea and wrap all API is better IMO
More work initially, but way more convinient and way more flexible

[Trishiraj]

Exactly my point, Not advising on per screen customisation. Rather having a custom wrapper for MaterialTheme itself in case you don't want to be using the default assigned parameters within the MaterialTheme colorSchemes