https://kotlinlang.org logo
Join Slack
Powered by
Hi, I have this dilemma my graphic designers prov...
# compose
u
Hi, I have this dilemma my graphic designers provide text styles, however the semantic names they use don't match material design naming & have more than default MD typography. (i.e. 
footnote
) What should I do? Should I create mental alias in my head, or should I provide extensions over 
Typography
(say like 
val Typography.subheadline
etc?) and implement all the names they use and simply don't use the names on 
MaterialTheme.typography
which are extra? Or should I create my own composition local and only use that, i.e 
MyTheme.typography
?
a
Your own composition local is a very flexible approach, if you don't want to be constrained by Material theme. Check out this page to see different approaches: extens, replace, write from scratch https://developer.android.com/jetpack/compose/designsystems/custom
u
but would you use it next to the 
MaterialTheme
or replace it?
ie. stock = MaterialTheme.typography, extra = MyExtra.typography
a
My design system differs heavily from Material, so I just ignore it completely)
u
but you do depend on Material Theme?
a
Nope
I have my own typography, colors and stuff
I use some Material Components, of course, but I take values from my own theme to customize them
u
so technically you CAN reference 
MaterialTheme.typography
in your composables, right? but simply pretend it's not there
a
Yeah, it just doesn't make sense, because MaterialTheme is not customized for my app, and will just use default values
u
gotcha, thanks!
btw if I were to go extension route - I should cache tye TExtSTyle instance right?
a
Now I lost you a little bit) Cache what where?
u
Copy code
// Use with MaterialTheme.typography.textFieldInput
val Typography.textFieldInput: TextStyle
    get() = TextStyle(/* ... */)
from the docs - this create a new instance every call, right? I'd expect to have 
private val foo = TExtStyle (..)
and then just return this instance in the extension getter
a
I think you shouldn't worry about that - couple allocations during composition is not gonna kill your performance
u
btw do you plug your theme as a composition local? or is it simply a static 
object
a
it's an object at the top level
u
yea thats what I mean - it's a sugar for the composition local , gotcha
a
We tried to mimc Material 2 theme code at the time of the design, so maybe some things are done better in Material 3
u
btw about the MD2 vs MD3 .. whats the difference? does it make sense to upgrade if I have my own graphic design, i.e. how Button looks etc?
a
It depends very much on a set of curcumstances) Some components are implemented better in M3 (fewer bugs, better API), some are worse, some are just different (Bottom Sheet, for instahce)
u
yea I was mostly looking at sheets ..
a
I use my own Theme and a combination of M2, M3 and completely custom components for design system implementatioon
u
hm, you can have both?
a
Sure, why not?
Sheets are full-screen dialogs in M3, and layouts in M2, which leads to a very different behavior and API, so choose wisely and experiment with both of them
u
what does that mean .. one thing I have in M2 was that, if I had a screen that has bottom navigation (bottom tabs), and if a child wanted to show a bottom sheet, the sheet would be inset visually, i.e. only in child's "window", which is not what I want
is this changed in m3?
a
Yes, that's one major difference. M3 bottom sheet will overlay the whole app, no matter where it's started from
u
oh fck great!
a
My thoughts exactly, but check out my thread 2 posts above. There are some caveats to be aware of
u
what caveats? that the api is different?
a
There are some implications of the fact that the bottom sheet is now a Window, for instance when you want to customize back handling
u
looks resolved?
okay so its better but has new bugs, the usual 😄
a
More like worked around, didn't get the chance to check it out yet. There's even a TODO in source code for this bug)
u
btw is M2 developed still? Im still confused, it seems as 2 standalone things, not necessarily that M3 is upgrade from M2, no?
a
They are both being developed, but M2 is currently in more of a support mode, while M3 is considered "current" design system. I expect Google to freeze M2 in a year or two, but I'm not Google, so you better ask them directly, they answer here sometimes)
u
right, thanks!
a
Got an interesting warning after updating to compose BOM 2024.02.01
u
so they don't want you to use both at once?
6 Views
Open in Slack
PreviousNext
Powered by