Can composable functions return something? I ran this code and got `java.lang.ClassCastException: ko...

# compose

[Grigorii Yurkov]

Can composable functions return something? I ran this code and got java.lang.ClassCastException: kotlin.Unit cannot be cast to java.lang.Boolean

[Luca Nicoletti]

No, you can’t return anything

[Luca Nicoletti]

Annotating a function or expression with [Composable] changes the type of that function or expression.

[Luca Nicoletti]

That’s why you get that exception, you’re trying to cast Unit which is what a @Composable function returns to Boolean

[Grigorii Yurkov]

Ok. And why it is not compile error?

[Grigorii Yurkov]

Looks like imperfection in compiler plugin

[Michal Bacik]

True, the plugin should check and show error if @Composable returns anything else than Unit.

[alexsullivan114]

Do we know if this is the plan moving forward? I remember someone mentioning the interesting prospect of returning values (not the composables themselves) from composable functions offering another interesting advantage of the current approach

[Luca Nicoletti]

From what I understood: no, that part will remain as it is

[Luca Nicoletti]

But I might be wrong 🙂

[Michal Bacik]

Just that they don't forget:
https://issuetracker.google.com/issues/143629513

[Leland Richardson [G]]

hmm. this is a bug, but also a bug that will soon become a non-bug, so let me explain….

right now, there is an expectation that @Composable functions return Unit, and we should report an error when the code tries to do something else like yours does. So that apparently is a bug you found for us.

That said, our plan is to open up the return value for composable functions as well, so this would make your code valid. It took us a little while to really wrap our heads around what this would mean and we believe we understand now. This change will also make it so that we can get rid of the concept of an “effect” in Compose (this is what uses the unary pluses right now). This is because it turns out that all of the functionality enabled by effects can be enabled by return values.

[alexsullivan114]

ooo fun

[Luca Nicoletti]

fuck* 🧌

[Michal Bacik]

When we'll learn what's the Effect, it will be gone 😳

[Leland Richardson [G]]

lol

[Leland Richardson [G]]

part of the reason we haven’t talked much about them…

[Leland Richardson [G]]

effects were complicated to work around something, and instead we just removed the something, no more need for effects…

[alexsullivan114]

I can't fully wrap my head around how you can get rid of effects (assuming effect = state in the react sense, which might be wrong) with return values but I'm excited to see

[Luca Nicoletti]

“Don’t fight the problem, decide it.”

[Leland Richardson [G]]

effect ~= hook in the react sense

[Leland Richardson [G]]

composable functions serve the same purpose as both react components and react hooks

[alexsullivan114]

Interesting

[Leland Richardson [G]]

the interesting bit is that compose works much more closely to the execution model of react hooks than react components

[Leland Richardson [G]]

but react couldn’t do things this way because the return value of the component is taken up by the elements its returning

[Michal Bacik]

When will you thrown new Compose version on us? Or how often you plan make canary releases?

[Leland Richardson [G]]

we are still working that out internally. will let you all know when we have news to share

[alexsullivan114]

I find the discussions around the internals of Compose suuuuuper interesting, but it's also very hard to follow. I know you had a great blog post a while ago kind of describing the approach, but in terms of the nitty gritty details is the best path forward to learn about some of the mechanisms behind compose just to read the source code?

[Luca Nicoletti]

go with repo 🧌

[Leland Richardson [G]]

hmm. i mean i think if that works for you its great, but i have personally found the answer to that question is “no” for the most part… it is very nice to be able to consult the source code to really understand things and that is one of the reasons why we wanted it to be open source, but also consider:

1. sometimes implementing something is much much more complicated than the simple mental model that encompasses it. I have found this to be true for compose. Some concepts are much easier to explain than to dig through the source code which must handle all corner cases and do so in the context of a very large code base with a lot of data structures and architecture that won’t be familiar.
2. some things are changing, and there’s a lot of vestigial stuff in the code even though it is still earlier. I’ve done an almost ground-up rewrite of our compiler like… 3 times now. lol. i’m not proud of that but it just is what it is. the way we think about this stuff has continuously gotten simpler and simpler… but some of the code still represents an older state and is more complex than it needs to be.
3. some things aren’t implemented yet and are kind of “hacked together” in ways that go against the way we want to do things, so it is incorrect to assume that it is going to stay that way and the way it is implemented might lead one to believe that certain things are possible/impossible but are the opposite in reality

[Michal Bacik]

What I find interesting and frightening at same time is that debugging inside of composable function shows 350 calls on stack frame. Full of invoke, Observe and few other. Isn't 350 nested calls too much?

[Leland Richardson [G]]

haha

[Luca Nicoletti]

Do you want your composable to recompose themselves or not? 🧌

[Leland Richardson [G]]

yes, it is 😉

[Leland Richardson [G]]

yeah the Observe calls in your stack trace will be going awya

[Luca Nicoletti]

Will you hide them, or shrink?

[Michal Bacik]

The thing is that one hierarchy level of composable function needs ~40 nested function calls, as I see in debugger. With deep hierarchy of composables, it may run out of stack memory.

[kioba]

hmm I wonder if Compose could handle a recursion 🤔

[Leland Richardson [G]]

we won’t hide them, they won’t be needed anymore

[Chuck Jazdzewski [G]]

More specifically we will replace them with a different code generation pattern that will not involve rewriting the function into a lambda passed to a helper. Instead if will conditionally create a lambda a the end of the composable function if it detects that the composable function might need to be restarted.

[Chuck Jazdzewski [G]]

This removes the two function calls per composable function call down to one so, at least it is ~175 instead of ~350

[Klaas Kabini]

These discussions are very interesting. As a result, I am learning a lot about the direction that compose is taking including the future changes. We have begun building an app that we are planning to launch in a few months to come using Jetpack Compose and patiently waiting for compose to become production ready.  We taking advantage of compose because 1) it gives us the ability to be in full control of the UI state and maintain a single source of truth, 2) it favours composition over inheritance allowing one to build lightweight UI components that are not polluted by what we don't need as is the case with inheritance, 3) it eliminates the hurdle of having to switch context between XML and code as in the old ui toolkit. 4)  it simplifies the task of writing UI tests 5) it simplifies the process of handling UI resources like theme colours, typography, dimensions, vectors. Honestly speaking, compose is a huge step in the right direction.