why compose uses sp, dp, instead of raw number jus...

# compose

[Karthick]

why compose uses sp, dp, instead of raw number just like flutter...🤔

[Brian Gardner]

I think it’s forcing the use of good patterns. Sizes should be declared in dp units so the sizes are the same on different screen densities. Text needs to be declared in sp units so it also resizes based on density but also takes into account the user’s text accessibility settings. Using a regular number would not support either of these cases

[Leland Richardson [G]]

number literals don’t have units, but unfortunately, ui’s do. We have pixel-space and dp-space and sp-space at least

[Leland Richardson [G]]

kotlin inline classes offer us an opportunity to make those units explicit while suffering very little in terms of overhead

[Leland Richardson [G]]

the ergonomic overhead is pretty minimal, we hope (ie, 16.dp instead of 16

[romainguy]

Having written so much UI/drawing code, this is one of my favorite features 😛

[Colton Idle]

As long as I can set things everywhere in dp. Maybe it's just me, but definitely in the current android toolkit I would do setSomething(sizeInPx) and I had to do the px to dp conversion myself. Which is fine... but it ended up being a util I had to add into every project, when it should have in fact just been handled by the api in my opinion. I still always refer to your stackoverflow answer @romainguy 😄

[Leland Richardson [G]]

yeah, i know what you mean

[Leland Richardson [G]]

i’m hoping that’s not the case here though

[Leland Richardson [G]]

generally speaking everything in user-land should be in dp.

[Leland Richardson [G]]

but once you get to lower level layers like layout and draw, we start to get into pixel-land

[Leland Richardson [G]]

and to complicate things even more, layout ends up working better when using int pixels

[Leland Richardson [G]]

and draw ends up working better when using float pixels

[Leland Richardson [G]]

we’ve explored a few different API shapes and directions to try and avoid this mismatch affecting the user as much as possible though. if you end up noticing one that isn’t this way, let us know

[Leland Richardson [G]]

for instance, some gesture events give you pixels which might be annoying if you’re using that value in user-land where dp is the thing you want

[Colton Idle]

That's really useful information. I will say that I'm a little surprised at hearing that "layout ends up working better when using int pixels" and "draw ends up working better when using float pixels". I'm sure it's so minimal that an app developer like me typically doesn't have to worry about it, but cool snippet of info!