A modern programming language that makes developers happier.

kotlinlang

What does wrapping things in a `LayoutNode` achieve? A `@Composable` already emits a group. Why can’t the group just be written to the composition? Why does it have to be nested in a `LayoutNode`?

Groups are essentially a control flow tree, nodes represent a resulting tree of UI elements.

Group is not nested in a LayoutNode, it is node that is put inside a group

image.png

<@UJNU95VNC> Sorry, I’m absolutely unable to understand that explanation. Jetpack Compose Internals by Jorge Castillo, which I’m more than a quarter of the way through, says that `LayoutNode` instances are added to the composition. That process includes a call to `content: @Composable () -&gt; Unit` sandwiched between `currentComposer.{start, end}ReplaceableGroup`. So its groups are nested in the replaceable group, are they not?

Also I don’t know why everybody directed me to this book. The book is maybe decent if you’re already familiar with the internals and just need a quick refresher, or you’re only looking for an incredibly vague and abstract gist of the system. It’s hand wavy about virtually everything. This whole section makes very little sense. Also, for what it’s worth, the whole book is riddled with typos and grammatical errors.

Maybe because there is no other book about this at all?

<@U010JQZ3FRC> You’d be surprised by how many drive-by links to the book I get when I ask questions about the internals as if I’d have known the answers to all my questions had I only read the book and I’m just lazy for expecting somebody to give me the answers here.

Yeah, it is very hand-wavey
If you are familiar with React, you can think about composition groups as React component tree and layout nodes as the resulting dom tree. Composition groups are storing the data that is specific to composition only, the layout nodes are used by external systems like layout and rendering

<@UJNU95VNC> I vaguely understand that a `Composition` is like a virtual DOM that the actual DOM is updated to match. But I thought materialising a tree from a `Composition` was supposed to happen after updating the slot table for example? Why is it happening in the middle of a `@Composable` call?

We create a node straight away, the tree is assembled after in the `applyChanges` phase

It is to do with making sure updates are handled correctly etc

&gt;  You’d be surprised by how many drive-by links to the book I get when I ask questions about the internals as if I’d have known the answers to all my questions had I only read the book and I’m just lazy for expecting somebody to give me the answers here.
I didn't say that. I just meant that if you were not referred to the book then you'd likely be referred to nothing.
Or to Andrei's brain directly, but the technology isn't there yet