I'm trying to decide how to preserve some compose state (specifically a List's scroll state). I have...

# decompose

[Adam Brown]

I'm trying to decide how to preserve some compose state (specifically a List's scroll state). I have screen A with the scroll state, and then screen B that uses the stack navigator to get pushed on top. And when that happens, I lose the state and remembers of screen A's composable. So when I pop screen B off the stack, screen A has lost where it was scrolled to in it's list. I think the strict compose answer to this is state hoisting. Something about that feels a little weird, but I suppose it can make sense?

[Adam Brown]

The only other thought I had was to put it in the Component's state object, but that is multiplatform and shouldn't have any knowledge of compose specifics.

[Adam Brown]

the more "Androidy" way would be to save the state in your ViewModel as that will survive the navigation

[Adam Brown]

our component here plays that roll, but again, can't/shouldn't have any compose specific stuff in it

[Adam Brown]

so I guess my question is just: What's everyone else doing, just state hoisting?

[Arkadii Ivanov]

remember is lost whenever the Composable leaves the composition, which happens on screen switch. However rememberSaveable should be automatically preserved if you use the Children function. LazyColumn should preserve its scroll state automatically as well.

[Adam Brown]

oh interested! I have a fairly custom lazyList here with my own state object, sounds like I just need to make that savable

[Arkadii Ivanov]

E.g. if you try the TodoApp sample, you will notice that the scroll state is preserved.

[Adam Brown]

aaahhh... I got too clever... I saw how in your master/detail you had the list pane just get hidden when a detail was over top, I tried to improve on that by removing it with a conditional… thus Children lost it's state

[Arkadii Ivanov]

That multi-pane sample is tricky and is there only to showcase dynamic multi-pane layouts. Each child is displayed in its own stack. In sone-pane mode, the main stack switches from visible Main to None (Main goes to back stack), and at the same time the details stack switches from None to Details (None goes to back stack). On back navigation, both stacks are popped. This was required for scroll state preservation when dynamically switching between single-pane and multi-pane modes, e.g. when resizing the window.

I think now it can be optimized by using movableContentOf. I will try to play with it again.

[Adam Brown]

oh I should check out that movable content thing, haven't even heard of it yet. I ended up just doing it myself with a BoxWithConstraints and some math

[Adam Brown]

I'm doing a fair bit of stuff where I reorganize the UI depending on if I'm in a portrait small screen configuration or a wider large screen configuration, sounds like movable content might be the ticket

[Arkadii Ivanov]

Yep, movable content is useful when you need dynamically switching layouts (e.g. on window resize). I'm going to push an update to the multi-pane sample in the coming days. Movable content worked and simplified things a lot.