Consider the following code

Column {
        var on by state { true }

        Button(onClick = { on = !on }) {
            Text(text = "Toggle", style = textStyle.h1)
        }

        val list = @Composable {
            LazyColumnItems(items = listOf(1, 2, 3, 4, 5, 6, 7, 8, 9, 10)) {
                Text(text = it.toString(), style = textStyle.h1)
            }
        }
        if (on) {
            list()
        } else {
            list()
        }
    }

Here we have a scrolling list, with a button above it, that seemingly, does nothing. However, it doesn't - it resets the current scroll progress in the scrolling list. I have a feeling this is the intended behavior (unfortunately). I have a less trivial case where the same list is being used at multiple places, but it loses its scroll progress when it gets invoked through a different branch of code. It might be possible to somehow structure the code such that only one invocation occurs, but I find that difficult. Is there some way to make compose understand this is the same list?

@Leland Richardson [G] Is that something that can be addressed with

key()

or am I incredibly mistaken here?

I can't think of a way to use that to solve this myself

No, key won't help you here. What you need to do is to pull the call to list up out of the conditional branch or hoist the state up.

Then you store things like the scroll position into myState

how can I store this if LazyColumnItems does not provide it?

You can't, unfortunately. That's why it's so important that all state be hoistable and why having truly private state (not hoisted) is such a bad practice. IMO,

LazyColumnItems

should expose scroll position, probably as a hoisted state object; please feel free to file a bug on

LazyColumnItems

(please be gentle on us though, keep in mind that this widget is still under active development/iteration and this API is not yet done)

I feel like I only need to get the column state because of the deeper problem, where I can't execute the same composable into different code paths. Why should I be forced to take care of

LazyColumnItems

's state? Imagine if the component had 20 different fields (or state variables, rather) that it uses to manage its state, do I then need to pull them up into my component and store them so the component I am using doesn't forget everything?

Hoisted state is generally stored recursively, such that a state object may store the state of all its children, and those children store the state of all their children. Using this pattern, a caller of a widget never needs more than one hosted-state parameter for that widget.

yeah if it’s just the scroll state that is the problem here, i think hoisting lazycolumnitem’s scroll position and using it in both branches seems like a good thing to do. if you actually want to preserve all state underneath it, i would need to understand more about the use case. we have thrown around ideas of “reparenting” APIs and similar that would allow you to do that but there’s a good chance your use case wouldn’t need you to go that far

hoisting the scroll position of

LazyColumnItems

is one of my next plans, so should be available at some point

The use case is something i've mentioned before, It's swiping between a list of components. As a primitive for that I have a component that is a

SplitView

, it shows 2 components side by side,

left

, and

right

. When swiping from left to right, the

left

component is the previous component, and the

right

component is the current component. When swiping from right to left*,* the

left

component is the current component, and the

right

component is the next component. In this case, the same component is represented as different arguments to the same method, so in the case of a scrolling list it would lose its scroll position when swiping.