https://kotlinlang.org logo
#compose
Title
# compose
g

Grigorii Yurkov

10/30/2019, 7:23 PM
Can composable functions return something? I ran this code and got
java.lang.ClassCastException: kotlin.Unit cannot be cast to java.lang.Boolean
l

Luca Nicoletti

10/30/2019, 7:33 PM
No, you can’t return anything
Annotating a function or expression with [Composable] changes the type of that function or expression.
That’s why you get that exception, you’re trying to cast
Unit
which is what a
@Composable
function returns to
Boolean
g

Grigorii Yurkov

10/30/2019, 7:35 PM
Ok. And why it is not compile error?
Looks like imperfection in compiler plugin
👆 1
m

Michal Bacik

10/30/2019, 7:40 PM
True, the plugin should check and show error if
@Composable
returns anything else than
Unit
.
a

alexsullivan114

10/30/2019, 7:48 PM
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
l

Luca Nicoletti

10/30/2019, 7:49 PM
From what I understood: no, that part will remain as it is
But I might be wrong 🙂
m

Michal Bacik

10/30/2019, 7:50 PM
l

Leland Richardson [G]

10/30/2019, 8:09 PM
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.
👍 1
a

alexsullivan114

10/30/2019, 8:11 PM
ooo fun
l

Luca Nicoletti

10/30/2019, 8:11 PM
fuck* 🧌
m

Michal Bacik

10/30/2019, 8:14 PM
When we'll learn what's the
Effect
, it will be gone 😳
🧌 1
l

Leland Richardson [G]

10/30/2019, 8:16 PM
lol
part of the reason we haven’t talked much about them…
effects were complicated to work around something, and instead we just removed the something, no more need for effects…
a

alexsullivan114

10/30/2019, 8:18 PM
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
l

Luca Nicoletti

10/30/2019, 8:18 PM
“Don’t fight the problem, decide it.”
l

Leland Richardson [G]

10/30/2019, 8:18 PM
effect ~= hook in the react sense
composable functions serve the same purpose as both react components and react hooks
a

alexsullivan114

10/30/2019, 8:19 PM
Interesting
l

Leland Richardson [G]

10/30/2019, 8:20 PM
the interesting bit is that compose works much more closely to the execution model of react hooks than react components
but react couldn’t do things this way because the return value of the component is taken up by the elements its returning
m

Michal Bacik

10/30/2019, 8:21 PM
When will you thrown new Compose version on us? Or how often you plan make canary releases?
l

Leland Richardson [G]

10/30/2019, 8:21 PM
we are still working that out internally. will let you all know when we have news to share
👍 1
a

alexsullivan114

10/30/2019, 8:23 PM
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?
l

Luca Nicoletti

10/30/2019, 8:23 PM
go with
repo
🧌
l

Leland Richardson [G]

10/30/2019, 8:29 PM
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
👍 2
m

Michal Bacik

10/30/2019, 8:37 PM
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?
l

Leland Richardson [G]

10/30/2019, 8:38 PM
haha
l

Luca Nicoletti

10/30/2019, 8:38 PM
Do you want your
composable
to
recompose
themselves or not? 🧌
l

Leland Richardson [G]

10/30/2019, 8:38 PM
yes, it is 😉
yeah the Observe calls in your stack trace will be going awya
l

Luca Nicoletti

10/30/2019, 8:44 PM
Will you hide them, or shrink?
m

Michal Bacik

10/30/2019, 8:44 PM
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.
k

kioba

10/30/2019, 8:45 PM
hmm I wonder if Compose could handle a recursion 🤔
🤷🏼‍♂️ 1
l

Leland Richardson [G]

10/30/2019, 8:46 PM
we won’t hide them, they won’t be needed anymore
👍🏼 1
👌 1
c

Chuck Jazdzewski [G]

10/30/2019, 9:48 PM
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.
👍 1
This removes the two function calls per composable function call down to one so, at least it is ~175 instead of ~350
k

Klaas Kabini

01/16/2020, 12:01 AM
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.
3 Views