This message was deleted.

# compose

[Slackbot]

This message was deleted.

compose.html

[Mark Murphy]

I find Compose impossible to understand

What you are seeking are details of Compose internals. Please bear in mind that the vast majority of Compose developers do not need this.

That said, there are existing resources that cover this material, such as Jorge Castillo's book.

[Mark Murphy]

Personally, I can't. I decided a long time ago that I was happy treating Compose as largely a magic black box and focused on how to use it rather than how the magic worked.

[yschimke]

The APIs you are asking about are really more for the implementators of a Compose based system on top of the general Compose Runtime. I'd suggest if you want to learn this level you might start with a simpler smaller compose system like Jake's Mosaic.

[Kirill Grouchnikov]

Depending on what the end goal is here (write your own book about Compose internals? write some sort of a separate system that is in the same rough vein as Mosaic? gain a deeper understanding how the internals work for your own knowledge of how a reactive toolkit works? something else?) - it might be that the best you can get is to track closely the commit history of https://cs.android.com/androidx/platform/frameworks/support/+/androidx-main:compose/runtime/runtime/src/;l=1;bpv=1 and, over time, build the mapping from CL descriptions to the specific places in the runtime module code that are touched.

Some of your questions are very deep in the internal implementation details that may - and frequently do - change over time. Without speaking for the core Compose team, some of the answers might just be "it was the most expedient thing to do at the moment".

[shikasd]

SlotTable holds the data about groups and slots for composition
Composer is an abstraction that modifies and reads SlotTable. It is responsible for handling startGroup / endGroup calls, so the slot table remains in the correct shape.
Composition glues together Composer , Applier, state observations and other things that composition does.
CompositionContext is an abstraction over parent-child relationship between compositions. Recomposer is a root driver that keeps the clock running, and most methods in the context just delegate there, but some things like CompositionLocalMap needs to be passed through when creating subcompositions.

[shikasd]

As a person who has spent a few months to understand the system from scratch for fun (before joining the team), I'd recommend to avoid going deep in every topic and ensure there's an understanding of how the whole thing fits together. It only gets worse as you go up the stack to LayoutNode etc.

You don't need to understand every single detail about composition, states and others to efficiently use those APIs. It is useful no doubt, but it simply takes too much time to understand every little edge case that was covered when implementing some of those elements.

In many cases, reading commit messages should give you some history for the decisions if you are interested. Some more tricky lines (cough.. derived state.... cough..) have layers of those decisions that are hard to explain without looking at the tests.

[shikasd]

Check how SubcomposeLayout works, it should give you a better idea about parent-child relationship. The recomposer contains a flat list that just maintains a list of active compositions to what to recompose, that's why most of the methods go back to it.

[shikasd]

CompositionContext is an abstraction over recomposer + parent composition local context, to simplify this a bit

[shikasd]

I recommend reading https://intelligiblebabble.com/compose-from-first-principles/ for a surface level understanding

For nested subcompositions, I recommend looking through SubcomposeLayout (which is also a bit of a mess admittedly). The idea is that some compositions might happen out of phase e.g. during measure and layout phases. The subcompositions keep composition local context of the parent group and some other things making it a tree

Recomposer does not care about compositions as a tree and only keeps them in a list right now. We want to make sure we recompose every active composition, it does not have to be in a tree structure for that.

[shikasd]

didn't shed much light on what I didn't already know

tbh it is enough to hand roll a small version of Compose imo :)

For other questions, see the comment above

For nested subcompositions, I recommend looking through SubcomposeLayout (which is also a bit of a mess admittedly). The idea is that some compositions might happen out of phase e.g. during measure and layout phases. The subcompositions keep composition local context of the parent group and some other things making it a tree