Have a question about theming. For things like typography, the values seem to be relatively static. However, if you look at material theme colors, those fields are specifically declared as mutable state and the constructor parameters are not properties, but simply values that are used for creating the mutable state instances. Why is this?
z
Zach Klippenstein (he/him) [MOD]
10/06/2020, 5:50 PM
I think it’s for animation, and colors are more likely to be animated between than typography.
m
mattinger
10/06/2020, 5:51 PM
It just creates a ton of boilerplate, since you have to:
• declare the constructor argument
• declare the mutable state field
• declare the argument to the copy function
• declare the argument to the updateFrom function
• declare the argument in the creation fuctions (ie. lightColors(), etc..)
z
Zach Klippenstein (he/him) [MOD]
10/06/2020, 5:53 PM
Not sure what you mean – you don’t need to do all that to use MaterialTheme
l
Louis Pullen-Freilich [G]
10/06/2020, 5:54 PM
Could you expand on the boilerplate? This is only needed if you are building your own custom themeable colors object, and you care about optimizing for usecases when it is being animated.
If you know that your colors will never change / animate, you can just define it as a normal data class / similar.
m
mattinger
10/07/2020, 7:22 PM
Thanks @Louis Pullen-Freilich [G]. I was wondering what the use case was for not making it a data class. I was simply duplicating what i saw in the MaterialDesign Colors class. Unfortunately our UX has their own design system they are working on which doesn’t match up with MaterialDesign.
To be honest, material design coloring rules can be confusing for a lot of people. Understanding what colorPrimary means and where it gets applied is a lot less clear than a property like: primaryButtonColor
And the linked nature of something like colorPrimary which can get used in multiple controls does kind of limit your color pallete. In general that’s a good thing unless your UX team doesn’t want to follow that.