A modern programming language that makes developers happier.

kotlinlang

image.png

but you should not put long text in the main thread but just a TLDR and then the rest in the thread, so that people on smartphoes do not have to scroll the long wall of text and screenshots if they are not interested in answering your question.

Subcomposition exists as a continuation of a composition tree, just composed independently. The place where context is remembered marks that place in the parent composition, so that composition locals and tooling calls are propagated correctly.

Composition does not reference its children directly for exactly that reason, because it makes no sense for it to do so. We want to compose it separately anyways, and the important part is to pass composition context (read composition locals) from the place it was created.

No, there's no limit for compositions. SubcomposeLayout uses the same context for all subcompositions

Kind of, composition does not order children outside of tooling really, it just registers them in the context

Generally, yes, it just happens to be ordered in the creation order, so parents are generally recomposed before the children
You can also subcompose in different order later (subcompositions are cached by key), and it will not change their order

The rendering order and recomposition order is different, rendering order is controlled by layout (order of placement + zindex)
There's a single composition context per SubcomposeLayout, it just indicates what state composition locals were in at the place where subcompose layout was inserted

<@UJNU95VNC> I meant the placement of a child composition within the parent. Slots for `Text`, `Column` instances are ordered but subcompositions in the same context are collapsed to a single slot

From the parent composition perspective, subcompositions don't really exist, only the context is in the slot table. You just connect it manually on the node layer.

<@UJNU95VNC> Ah, so it’s the job of a subcomposition applier?
• A `Composition` can create and remember children of its `CompositionContext`.
• A `Composition` in a child `CompositionContext` (‘subcomposition’) can be materialised as a subtree by an `Applier` implementation that does so.
Have I got it right now? Or are subcompositions always necessarily materialised as subtrees regardless of how a given `Applier` works?

ChatGPT says that the summary is correct and that it does depend on the `Applier`, which I’m hesitant to believe. I’ve still been making progress through Jetpack Compose Internals by Jorge Castillo also, but the book doesn’t really contain anything of substance that’s useful.

It is a job of SubcomposeLayout really, applier will just create subtrees in the node it is given

<@UJNU95VNC> How does `SubcomposeLayout` do it?

I makes the child nodes per subcomposition and then composes into those nodes during measure / layout