In our team Compose sparkled a lot of discussion. DSLs in Kotlin don’t need a compiler plugin. Why i...

# compose

[ralf]

In our team Compose sparkled a lot of discussion. DSLs in Kotlin don’t need a compiler plugin. Why is compose different? Why is the compiler plugin necessary? Is it just there to avoid some boilerplate? (I haven’t looked at the source, yet)

[louiscad]

Notice that @Composable annotated functions don't have a return type. So a compiler plugin is needed to pass down the tree where the widgets will be added (if they are not already present). This is similar to how kotlinc compiles functions with the suspend modifier to functions with an extra Continuation parameter.

[Marko Mitic]

silly question, why wouldn't something like this work?

fun myWidget() = compose { ...UI...}

[romainguy]

@Marko Mitic What would compose do here? You need a composition context of some kind

[romainguy]

The compiler also enables a lot of interesting things

[romainguy]

Esp. around optimizations

[romainguy]

For instance if your composable is just Text("Hello") the compiler can know it's constant at runtime and doesn't need to be checked for updates during the recomposition phase

[Marko Mitic]

Thanks for explaining. What version of AS do you expect to get Compose support?

[romainguy]

Impossible to say at this point

[ralf]

You also mentioned multithreaded UI during the talk. I guess this could be backed into the compiler plugin. The contra against a compiler plugin is that it’s harder to debug, because a lot of the magic is generated code. But this is more of a tooling concern and I really hope that the Kotlin compiler plugin will make this easier.

[themishkun]

@romainguy Decision to make functions return Unit and use compiler plugin instead of emiting specifications vie e.g. data classes will rise over and over again. I think you should write a blogpost regarding your thoughts about different approaches to model a view

[romainguy]

@ralf If we could @Composable would be a composable keyword and then it would be very similar to how coroutines work and we wouldn't be having this discussion :))

[romainguy]

@themishkun A big reason for us to return Unit is to avoid confusion I've seen developers have with say the flutter approach. Where you create what seem to be UI widgets but they're not, yet you have handles to them and it's unclear why you can't act on them

[ralf]

Probably :)) But I agree that a blog post would be really helpful where you explain certain design decisions even during this early stage.

[romainguy]

There are other things we'd like to do that would not be possible without compilation magic

[elizarov]

I personally liked main() { println(...) } analogy from presentation a lot. It really makes UI programming more approachable, easier to understand.

[romainguy]

Interestingly someone on Reddit saw compose and thought it was an immediate mode UI toolkit

[romainguy]

And the shape of it is indeed very close to immediate UI toolkits

[ralf]

Oh, that’s an interesting comparison with the main function.

[Felix]

I think I understand the rationale. However my first impression was that it is odd that a composable function should be a "pure function" (https://android.googlesource.com/platform/frameworks/support/+/androidx-master-dev/compose/README.md), however it returns Unit.

[stkent]

+1 that's a slightly odd use of pure. Also the README includes this line:

We are transitioning from the KTX syntax to using a Kotlin DSL based on intercepted function calls.

which seems to conflict with Romain's "you shouldn't think of Compose as a DSL" clarification.

[stkent]

(I don't know what a better description would be, however.)

[romainguy]

It's just function 🤷‍♀️

[romainguy]

I see no reason to call this a DSL