https://kotlinlang.org logo
#decompose
Title
# decompose
a

Adam Brown

01/29/2023, 1:33 AM
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?
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.
the more "Androidy" way would be to save the state in your
ViewModel
as that will survive the navigation
our component here plays that roll, but again, can't/shouldn't have any compose specific stuff in it
so I guess my question is just: What's everyone else doing, just state hoisting?
a

Arkadii Ivanov

01/29/2023, 1:49 AM
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.
a

Adam Brown

01/29/2023, 1:50 AM
oh interested! I have a fairly custom lazyList here with my own state object, sounds like I just need to make that savable
a

Arkadii Ivanov

01/29/2023, 1:50 AM
E.g. if you try the TodoApp sample, you will notice that the scroll state is preserved.
a

Adam Brown

01/29/2023, 2:42 AM
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
a

Arkadii Ivanov

01/29/2023, 10:26 AM
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.
a

Adam Brown

01/29/2023, 8:38 PM
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
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
a

Arkadii Ivanov

01/29/2023, 8:51 PM
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.
7 Views