https://kotlinlang.org logo
Title
a

Adam Powell

11/26/2020, 3:46 PM
We've decided against typealiases for this sort of thing in the compose API. An aliased type name can tell you a bit about what the intended usage is, but then you still have to hold in your head/look up what the type actually is in order to provide one. In contrast, the function type clearly describes the type and the parameter name describes its purpose; you have everything you need to know at a glance even if it's an API you don't use often enough to commit to memory.
b

Big Chungus

11/26/2020, 3:47 PM
Would be good to have typealias provided regardless (even if not used internally) for convenience when declaring your own composables
o

olonho

11/26/2020, 3:49 PM
Nobody prevent you to create such typealiases, and use them as needed.
4
b

Big Chungus

11/26/2020, 3:50 PM
I know, it's just standartisation issue. Instead of having users declare their own and then confuse others when sharing code, I think it'd be beneficial to have some "official" typealiases provided so we're all on the same page.
Again, it's a mater of convenience, so not having them is definitely not the end of the world 😄
a

Adam Powell

11/26/2020, 3:51 PM
Agreed about it being good to have standards, the full function type is the standard. 🙂
👍 8
In the presence of typealiases users need to know both expressions of a concept to be productive in a codebase
t

Timo Drick

11/26/2020, 9:31 PM
Maybe the only problem is that IntelliJ IDE do not show the @Composable annotation in the preview. So maybe in the future it could also display the annotation than it is clear that this parameter expects a composable.
👍 1
Or maybe like in other cases the IDE could just show composable instead of the type.
m

Martin Nowosad

11/27/2020, 10:13 AM
function type clearly describes the type and the parameter name describes its purpose
I beg to differ,
title
definitely doesn’t feel like you have to pass in a function and seeing
() -> Unit
as parameter doesn’t express anything neither
a
Composable
as type would be easier to understand and more readable
I agree with Timo, if IntelliJ could show the annotation then this would also help
but maybe I’m also not just used to it. Personally, I find code that is built around lambdas / builder methods difficult to read
t

Timo Drick

11/27/2020, 3:26 PM
Yes but for me the felxibility worth it. Because in the legacy material design views it is very hard to modify it to your needs. And at the end you have to build everything from scratch. I like the courrect trend in compose to make the things much more adaptable. Still many things i would like to adapt are internal but much better than in the old view system.
a

Adam Powell

11/27/2020, 3:36 PM
Agreed that not showing the annotation here hurts legibility. That's only part of it though; the formatting of this pop-up in general should also evolve. Adding the annotation without allowing the pop-up to format into additional lines will exacerbate the existing noisy hint popup problem that already appears with other kotlin APIs that include more than a few parameters and heavy use of default values.
👍 2
g

gildor

11/29/2020, 5:50 AM
I think showing annotation for lambdas in such popups is very noisy something like an icon would be nice (similar how suspend functions are marked)
4