Do you think conditional colors should be set by U...
# compose-android
l
Do you think conditional colors should be set by UI state emitted from a
ViewModel
or should colors be determined from within the UI based on more abstract UI substate? (Imagine a color that changes based on whether or not there is an error.) I am trying to deduce whether our practice of determining colors in the VM layer (we actually have a “transformation” layer that transforms a VM’s internal state to UI state) was poor practice. In the XML view paradigm, we could easily set colors into UI state emitted by the
ViewModel
using color resources. However, with compose color themes provided by `CompositionLocalProvider`s, we can’t do such a thing! The declarative UI ideal is that UI state should describe how the UI should look. It seems the color might need to be a part of that description at times.
k
Is the assumption that all colors must be provided by the composition locals, and can’t be passed down explicitly as part of your presentation models?
l
Yes. That seems to be the ideal 🤔
k
How so? Composition locals are good for something that is global, such as the top-level theme (colors, typography, etc). For your conditional colors, pass them as part of your configuration into the specific composable. That way it’s easier to reason how a specific composable is configured, easier to test, easier to use (with reasonable default color values).
☝🏿 1
l
Isn’t it just fundamentally wrong to have UI classes in the VM layer? In this case it would be
Color
.
m
I think what Kirill is suggesting is that the leaf composables take a
Color
. You are trying to determine whether you can use an abstraction first and derive that
Color
outside of the viewmodel. Those two things are not necessarily in conflict. Some higher-order composable (e.g., a design system wrapper) could derive the
Color
from the abstraction, and use that
Color
with the leaf composable(s) that render the UI.
☝🏿 1
l
I am trying to determine if it is stupid bad practice to set a
Color
from the
ViewModel
.