I have a question regarding using `Layout`, how it...

# compose

[Stylianos Gakis]

I have a question regarding using Layout, how it’s used in the implementation of Column|Row measure policy and in a codelab. More in thread 🧵

[Stylianos Gakis]

I was looking at this line which initializes something right before the layout call, just like I can see it’s done in this codelab, in the code-snippet right above the “MyOwnColumn in action” section.

However then looking for this in cs.android I found this, which is the same snippet but with the y-coord being initialized inside the layout block.

From my understanding that layout block can be called independently from the rest and more than one time as

shown here▾

, which makes me feel like you’d want to make these initializations be inside the block in which they are being used. Does it just not matter, or are some of these snippets slightly wrong or am I missing something?

[Albert Chang]

What are you actually concerning? The only difference is that mainAxisPositions won’t be GCed after layout block is executed.

[Stylianos Gakis]

What I was basically wondering is that if yPosition is initialized outside of the layout block as 0 for example. But the layout block is called twice, wouldn’t the old reference of yPosition still be referenced, which after the first layout call was made it’d not be 0 anymore?
And if that’s not the case, how is it not the case? It just feels like a basic concept that both calls to it are referencing to the same mutable variable that is outside of their scope, which would mean that it might interfere with each other. I must be missing something, feeling kinda dumb even asking this, but what is it that I am missing?
Unless the layout block isn’t just called separately from the rest of the code that’s above as I understood from the Deep dive into Jetpack Compose layouts video that I linked in my comment above.

[Zach Klippenstein (he/him) [MOD]]

It looks like that array is used to store the output of the arrangement function, which means it's always going to be written to first before being read later in the layout block.

[Stylianos Gakis]

Aha I see what you mean for the arrangement block, it’s a bit less simple than the other example, so let’s focus on the simple example with the yPosition.
In the codelab snippet, the yPosition isn’t written to first. It’s instead initialized outside of the `layout`’s placementBlock and it’s then being read and written to inside the `layout`’s placementBlock block.

[Zach Klippenstein (he/him) [MOD]]

There were a lot of links lol – which one are you referring to now?

[Stylianos Gakis]

Yeah mb. I was referring to this codelab now on the 2nd from last snippet, right above the text that reads “MyOwnColumn in action”

[Stylianos Gakis]

And I was referring to how in this snippet in cs.android it is initialized inside the layout block as I would suspect would be the correct way to do this. Since from the video I linked they imply that this block may be run independently, and I’d assume it would want to not use old references to a mutable variable that may have been mutated from a previous call to this block.
I am having a bit of a hard time to explain exactly what I am referring to considering there are so many things I am referring to, sorry for that, please point out if something still doesn’t make sense so that I can help clarify

[Albert Chang]

Yeah I think in the codelab case it can be a problem though there is no state reads in the layout block so it won't actually be re-run independently. Surely better to not rely on this behavior.

[Stylianos Gakis]

Alright, so it is a potential problem then. Even if there’s no state being read inside this layout doesn’t mean that just like in that video there could be some other modifier which does do that, making all the layout blocks to be re-run making this potentially work wrong right?

If that’s the case maybe this codelab may need this to be fixed to avoid people referring to it to get inspiration for similar use cases and having things work wrong for them.

[Albert Chang]

I think in 1.1 layout modifiers actually have their own scope. See this CL.

[Stylianos Gakis]

Not sure I understand this, but by “have their own scope” I assume that means their own recomposition scope (if you can call it that, idk. I mean that it will run again if some state has changed that’s referenced inside that block’s scope). But having their own scope doesn’t mean they’re not accessing the common mutable state that’s outside of their scope does it? The fact that they might re-run individually without having the outer block run if anything makes this case possible since that yPosition would be referencing the same old reference which is not 0.
I believe I am really out of my league with this discussion tbh, maybe what I’m thinking about doesn’t make sense 😅

[Albert Chang]

I don’t actually understand what you mean. Layout modifiers can be re-run individually without the layout block in Layout being re-run so yPosition is irrelevant here. The result of Layout is cached and layout modifiers can’t access yPosition.

[Stylianos Gakis]

Anyway I don't know how to better explain what I meant aside from this comment here, so if that doesn't make sense then whatever. I appreciate you trying to help though of course!

[Albert Chang]

I understand the comment you referenced and it is indeed a potential bug. That’s why I said “Surely better to not rely on this behavior”.
I was arguing against this part:

Even if there’s no state being read inside this layout doesn’t mean that just like in that video there could be some other modifier which does do that, making all the layout blocks to be re-run

[Stylianos Gakis]

Aha now I get it. Sorry I got a bit confused about which thing you were referring to. So what I said there is wrong because as you said it would simply not re-run if that itself doesn’t read the state that has changed. Again thanks for bearing with me on this one, I feel a bit more comfortable with these concepts now after this discussion 🙌