https://kotlinlang.org logo
#compose
Title
# compose
u

ursus

02/27/2024, 12:46 PM
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

alaershov

02/27/2024, 12:48 PM
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

ursus

02/27/2024, 12:53 PM
but would you use it next to the
MaterialTheme
or replace it?
ie. stock = MaterialTheme.typography, extra = MyExtra.typography
a

alaershov

02/27/2024, 12:54 PM
My design system differs heavily from Material, so I just ignore it completely)
u

ursus

02/27/2024, 12:54 PM
but you do depend on Material Theme?
a

alaershov

02/27/2024, 12:55 PM
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

ursus

02/27/2024, 12:59 PM
so technically you CAN reference
MaterialTheme.typography
in your composables, right? but simply pretend it's not there
a

alaershov

02/27/2024, 1:00 PM
Yeah, it just doesn't make sense, because MaterialTheme is not customized for my app, and will just use default values
u

ursus

02/27/2024, 1:00 PM
gotcha, thanks!
btw if I were to go extension route - I should cache tye TExtSTyle instance right?
a

alaershov

02/27/2024, 1:01 PM
Now I lost you a little bit) Cache what where?
u

ursus

02/27/2024, 1:01 PM
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

alaershov

02/27/2024, 1:08 PM
I think you shouldn't worry about that - couple allocations during composition is not gonna kill your performance
u

ursus

02/27/2024, 1:14 PM
btw do you plug your theme as a composition local? or is it simply a static
object
a

alaershov

02/27/2024, 1:15 PM
it's an object at the top level
u

ursus

02/27/2024, 1:16 PM
yea thats what I mean - it's a sugar for the composition local , gotcha
a

alaershov

02/27/2024, 1:17 PM
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

ursus

02/27/2024, 1:18 PM
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

alaershov

02/27/2024, 1:25 PM
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

ursus

02/27/2024, 1:25 PM
yea I was mostly looking at sheets ..
a

alaershov

02/27/2024, 1:25 PM
I use my own Theme and a combination of M2, M3 and completely custom components for design system implementatioon
u

ursus

02/27/2024, 1:26 PM
hm, you can have both?
a

alaershov

02/27/2024, 1:26 PM
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

ursus

02/27/2024, 1:30 PM
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

alaershov

02/27/2024, 1:30 PM
Yes, that's one major difference. M3 bottom sheet will overlay the whole app, no matter where it's started from
u

ursus

02/27/2024, 1:31 PM
oh fck great!
a

alaershov

02/27/2024, 1:31 PM
My thoughts exactly, but check out my thread 2 posts above. There are some caveats to be aware of
u

ursus

02/27/2024, 1:32 PM
what caveats? that the api is different?
a

alaershov

02/27/2024, 2:10 PM
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

ursus

02/27/2024, 2:38 PM
looks resolved?
okay so its better but has new bugs, the usual 😄
a

alaershov

02/27/2024, 2:39 PM
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

ursus

02/27/2024, 2:40 PM
btw is M2 developed still? Im still confused, it seems as 2 standalone things, not necessarily that M3 is upgrade from M2, no?
a

alaershov

02/27/2024, 2:43 PM
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

ursus

02/27/2024, 2:43 PM
right, thanks!
a

alaershov

02/28/2024, 6:38 AM
Got an interesting warning after updating to compose BOM 2024.02.01
u

ursus

02/28/2024, 2:34 PM
so they don't want you to use both at once?