Using the new styleable apis, how can we fetch the...

# compose

[andrew]

Using the new styleable apis, how can we fetch the current contentColor applied arbitrarily? I have an imageVector I want to tint, but would need to fetch the current, inherited contentColor. On web css it's as simple as using currentcolor. Is this something that will be simplified and brought over, or do I need to just dig through the internals for now?

[Stylianos Gakis]

Do you mean fetching it so that it will be used in composion? Because that is not possible at the moment, as it means you'd be back in composition phase and they are designed for layout/draw only.

[andrew]

Gotcha 👌🏻

[andrew]

I just noticed in the docs that it did mention icon styling, which is why I ask. I guess they mean fonts here? blob shrug

[Stylianos Gakis]

I must admit I haven't played with these apis myself yet. But maybe there is a way to give your icon a style and have it be applied as a tint. Try to look at the samples they have perhaps to see if they have such an example

[andrew]

I've been looking and nada, maybe someone working on the API at Google might know? 🤷🏻‍♂️

[Chuck Jazdzewski [G]]

There is currently no way to read back the resolved style. It is only resolved and read by the styleable() modifier.

However, we will make these values like contentColor available but the mechanism and API is still TBD.

[andrew]

Gotcha! I'll keep my eyes out for those changes then

[andrew]

Thanks for the clarification

[andrew]

Another related question - will there be a way to access contentColor values inside a nested stylescope?

Box(Modifier.styleable(null, { contentColor(Color.Black) })) {
    Component()
}

@Composable
fun Component() {
    Box(Modifier.styleable(null, { borderColor(/* FETCH CURRENT CONTENT COLOR */) })) {}
}

[Chuck Jazdzewski [G]]

There is no plans for a style to be able to read properties.

What would you do with this?

[andrew]

Similar to how css has currentcolor, it would be more for matching whatever the current content color would be, outside of text. Say I have a selectable card, and I want the outline color to match the content color in most, if not all cases. I might be inclined to fetch the current content color, and apply it there

[andrew]

(say the outline was nested below in a box)

[Chuck Jazdzewski [G]]

Our plan is to move the contentColor out of the style properties and let you set "inherited" properties though the modifier local (or similar, details TBD). This would then allow you to set the contentColor in a custom property and then use the style to map these properties into the style properties using a style. This would allow reading the property as you specified here these values would be readable in a style.

The reason to avoid reading properties is that it turns some of the properties into magic properties that may have surprising effects. For example, assuming the style was { borderColor(contentColor) }, what would it mean to change contentColor after this style is applied? Would you expect the above to match the resolved value or the value at the time it was executed? In other words, what is the borderColor for,

{
  contentColor(Color.Green)
  borderColor(contentColor)
  contentColor(Color.Red)
}

It seems obvious here that the color is Color.Green but less obvious if the first two are in a different style (say the base style for a component) and the last is an override such as,

Button(..., style = { contentColor(Color.Red) }) { ... }

Whoudl the border color be Green or Red?

I want the style properties to have a very specific, well-defined meaning. Meta properties, like contentColor should be defined by the theming system which moving this out of the style properties allows.

[andrew]

Okay, that makes sense! At least then, it'll feel like a more familiar pattern.

As for that example though, I would imagine inside the same block, it wouldn't manipulate the value, however, if it were under a child composable, it would inherit from the parent.