In Jetpack Compose, Composable functions build up the Composition tree when they execute for the first time, and then update it on every recomposition.

Here is a thread about Composition and node types in Compose. It covers both Compose UI and the Compose runtime 🧵 Here is a diagram of how recomposition (meaning re-executing Composable functions) updates the node tree representation (Composition).

Mosaic by @JakeWharton is a nice case study for how to create a client library for the Jetpack Compose compiler and runtime. Some pointers on where to find the key pieces in Mosaic, if you are interested 🧵

github.com/JakeWharton/mo… Any client library needs to define its own nodes and teach the runtime how to materialize them (provide an Applier). I.e: Teach it how to build and update the tree.

Here are the Mosaic nodes and the Applier implementation 👇 (2/*)

github.com/JakeWharton/mo…

Some people seems a bit confused about when to use `composed` to write a custom Modifier in Jetpack Compose, and when to use the `then` extension function instead. Well, they are actually very different. Let me expand on this just a bit 🧵 A "standard" modifier is written using the `Modifier.then` function over the modifier object, or a previous modifier instance. All the modifiers we use daily are written like this, making use of an extension function for ergonomics.

When thinking about Compose it's good to notice that Composables don't yield actual UI, but "emit" changes to the in-memory structure managed by the runtime (slot table) via the Composer.

That representation has to be interpreted later on to "materialize" UI from it 🧵 An example of this is the Layout Composable, used to implement UI components. Layout uses ComposeNode to emit changes about how to create, update, index, and store the node on the table. That's why Composables return Unit 😲

cs.android.com/androidx/platf…