Hi <@UK5SVA94Z>, may I ask a question about theming in compose. I have a situation where my primary ...

# compose

[Archie]

Hi @nickbutcher, may I ask a question about theming in compose. I have a situation where my primary color shouldn't be used for components that by default uses the primary color. for example: my primay color is Red so when using TextField, its active color defaults to Red. But I don't want it red but instead I need its active color to be Blue. If I understand it correctly, I would just have to create my own TextField and replace the active color. But then I look into Composable functions that create TextField and there are two. I would then have to have my own version of these two TextField Composable function with the overriden active color to Blue. It was fine here since there are only two functions I have to modify, but I was thinking what if there was more than two of these function or maybe in the future there may be additional of these functions. Is this the correct way to approach this problem?

[nickbutcher]

There are 3 possible approaches here:

1. Specify a different activeColor at call sites
2. Wrap the TextField composable(s) in your own composable which configures the activeColor param to something else and use your composable throughout.
3. Create a 'theme overlay' another theme the sets primary to your blue color and wrap components that don't want to use the red primary in that.
cc @Louis Pullen-Freilich [G]

[nickbutcher]

1. Would get pretty tedious and error prone

[nickbutcher]

2. Would look like this:

@Composable fun MyTextField(
  // copy all params from TextField
  activeColor: Color = // your blue color,
) {
  TextField(
    // forward on params
  )
}

Then you have to use this throughout. You'd obviously have to do this for all composables which you want to change the default color.

[nickbutcher]

3. Would looks like this:

Define two themes

@Composable fun RedTheme(…) {
  MaterialTheme(
    …
    colors = redColors
  )
}

@Composable fun BlueTheme {
  MaterialTheme(
    colors = blueColors
  )
}

Then use the RedTheme for most of the app but in places you want to deviate, wrap them:

…
BlueTheme {
  TextField(…)
}

[Archie]

@nickbutcher, Thank you very much. I am actually using approach 2. My only concern is it could be very tedious to maintain as Compose Grow. But maybe that how it is.

Thank you very much for the info.

[nickbutcher]

I think of 2 as the equivalent of an xml style. Let us know how you get on

[Yann Badoual]

Reading this gave me an idea of external lib that could be useful (or not). An annotation processor for a @ComposableAlias annotation that you could set on a function, and said function would define only parameter that you want to override default value for. And it would generate the content, not having to keep the signature up to date each time to composable changes.

ie:

@ComposableAlias("TextField")
fun CustomTextField(
   activeColor: Color = myCustomActiveColor
){
    // Empty
}

And it would generate a full composable with complete signature for each TextField function having an activeColor parameter

[Archie]

I think thats a good idea..

[Yann Badoual]

Tried to implement it, but I'm having an issue, the annotation processor lib won't return the methods if one of the argument is not in the processor's classpath. And I can't import compose in a java-lib. And making it an android-lib won't work because then I don't have the AbstractProcessor class in the classpath 🤷‍♂️

[Colton Idle]

@nickbutcher I followed your Option 3 today and it worked flawlessly, but I wasn't able to find this pattern in the docs. Unless I'm looking in the wrong places. Is this still the preferred route? It just makes a lot of sense and is simple.