Hello everyone, I was checking the source code of ...
# compose
o
Hello everyone, I was checking the source code of Material Theme declaration in Compose (alpha11) I realized that the classes :
Colors
and
Typography
are annotated with different annotations
@Stable
for the first and
@Immutable
for the second. Does this mean at a higher level that The Material Theme Composable expect colors to change at a moment of time (dark/light) but not expecting a change of typography ?
🤔 1
f
Yes, typography in most apps rarely changes (my observation at least), so there is no need to back it up by state. See https://kotlinlang.slack.com/archives/CJLTWPH7S/p1601558624316400?thread_ts=1601557054.315600&cid=CJLTWPH7S (and other threads by searching
typography state in:#compose
) 🙂
👍 1
o
Cool thanks 👍 This means when writing a custom non material theme, if typography is a subject to change (like font customization by the app user) we will need to align with the colors declaration with state backed properties and strict comparaison.
f
It's not strictly necessary, but using state for this stuff is the right way to go (don't know whether there will be noticable performance difference tho)
👍 1
l
Cool thanks 👍 This means when writing a custom non material theme, if typography is a subject to change (like font customization by the app user) we will need to align with the colors declaration with state backed properties and strict comparaison.
The other thing to note is that colors will often change individually. For example, if you have some album art and you want to change the
primary
color to match the album - you are changing one color, not all of them. If a user is changing the font in the application, it is likely that all the text styles will need to change, so at that point there might not be much benefit from having the properties being state backed, and you can just change the value provided to the
CompositionLocal
instead
👍 3
o
Thanks @Louis Pullen-Freilich [G] for bringing more light to the subject : )