One Off the Slack: When Do We Enter, and When Do We Leave?

Dmitry Suzdalev asked:

When we say that something “enters the composition” or “leaves the composition”, what does this mean exactly? I noticed that I’ve started to think about @Composable functions as objects in this regard, but that’s not true, is it? A function itself doesn’t have anything to do with composition lifecycle: only its effects do. Is there some good mental model to think about this?

Stylianos Gakis tried to explain:

If you have some code that looks like:

var someVar: Boolean
if (someVar) {
    MyComposable()
}

When someVar becomes false, the MyComposable leaves composition as it no longer is shown. remembers inside the composable function itself get destroyed etc.

When it becomes true again, MyComposable gets put back into the slot table, therefore all of its LaunchedEffect(Unit) etc. are run. It “enters composition”.

This is the first thought that comes to my mind when you say all this, is this what you’re looking for? If not please ask away. I do not know what you mean exactly by saying that you’re thinking of them as objects.

Dmitry was… less than comfortable with that explanation:

you say “it no longer is shown”: what is “it” here? A composable function? But function is not shown, it’s an entity of the programming language 🙂 This is what I mean when I say I start to think about them as “objects”.

I understand how it works, but I wonder if this can be formulated better from a structural point of view, when explaining things to someone. Or do we have to explain slot table whenever we want to deepen the understanding? Maybe there’s something in-between.

Stylianos understood the frustration with terminology:

You’re right that “shown” is not the right verb for this, I agree.

I find it the easiest to think as you said exactly, it leaves the slot table, therefore it no longer exists. The function no longer emits the UI it would emit if it was present in the slot table.

And you’re right that a function is not shown. I like to think of it as a functionemits UI, as that is what Unit returning composable functions do.

Dmitry agreed:

That’s mostly how I came to think about this too. And if we store comosable functions in the map or graph (like in navigation library), this doesn’t mean that we store “components”, we actually store “recipes” (?) to produce those components.

Then, Google’s Zach Klippenstein weighed in:

You can also describe it a bit more concretely as “a composable is present if it was called in the last composition pass/frame¹, and it is not present if it was not called in the last composition pass/frame.”

¹actually the last composition that was actually applied, but I’m guessing if you’re still trying to wrap your head around presence that distinction isn’t helpful

Read the original thread in the kotlinlang Slack workspace. Not a member? Join that Slack workspace here!