Can composable functions return something? I ran this code and got

java.lang.ClassCastException: kotlin.Unit cannot be cast to java.lang.Boolean

No, you can’t return anything

Ok. And why it is not compile error?

True, the plugin should check and show error if

@Composable

returns anything else than

Unit

.

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

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

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

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.

ooo fun

fuck* 🧌

When we'll learn what's the

Effect

, it will be gone 😳

lol

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

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

effect ~= hook in the react sense

Interesting

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

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

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

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?

go with

repo

🧌

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

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?

haha

Do you want your

composable

to

recompose

themselves or not? 🧌

yes, it is 😉

Will you hide them, or shrink?

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.

hmm I wonder if Compose could handle a recursion 🤔

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

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.

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.