We've decided against typealiases for this sort of...

# compose-desktop

[Adam Powell]

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.

[Big Chungus]

Would be good to have typealias provided regardless (even if not used internally) for convenience when declaring your own composables

[olonho]

Nobody prevent you to create such typealiases, and use them as needed.

[Big Chungus]

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.

[Big Chungus]

Again, it's a mater of convenience, so not having them is definitely not the end of the world 😄

[Adam Powell]

Agreed about it being good to have standards, the full function type is the standard. 🙂

[Adam Powell]

In the presence of typealiases users need to know both expressions of a concept to be productive in a codebase

[Timo Drick]

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.

[Timo Drick]

Or maybe like in other cases the IDE could just show composable instead of the type.

[Martin Nowosad]

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

[Martin Nowosad]

a Composable as type would be easier to understand and more readable

[Martin Nowosad]

I agree with Timo, if IntelliJ could show the annotation then this would also help

[Martin Nowosad]

but maybe I’m also not just used to it. Personally, I find code that is built around lambdas / builder methods difficult to read

[Timo Drick]

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.

[Adam Powell]

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.

[gildor]

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)