https://kotlinlang.org logo
#compose
Title
# compose
s

semoro

04/11/2020, 4:22 AM
I’m trying to implement list with animated swipe removal Do I really have to use
stateFor
and provide some key? https://gist.github.com/semoro/ea7c07cf3bcbd3bc4cbc4729b82b4140#file-composeremovalarea-kt-L64 Actually, if I don’t provide some kind of this id parameter, button click also hides subsequent list element, which is a bit counter-intuitive. Is it due to that changes of input parameters in RemovalArea’s child doesn’t cause recompose in RemovalArea itself, and previously occupied slot for deleted element became used by next one, without reset of state? Is there is some way to avoid passing
id
parameter?
t

Timo Drick

04/11/2020, 12:32 PM
Wow nice approach. Sorry can not really help. But thanyou very much for sharing. I currently thinking of how to implement list animations. And this looks very good. Clean and short implementation 👍
s

semoro

04/11/2020, 1:08 PM
I’ll update it once I’ll fix that problem than 🙂
Could also share swipe handler like in GMail items
z

Zach Klippenstein (he/him) [MOD]

04/11/2020, 2:04 PM
What happens if you add the
@Pivotal
annotation to `RemoveArea`'s
id
parameter? That should mean you don't need
stateFor
anymore, and should all preserve your other list items' state across list modifications (ie supports "moving" groups around). I think you need
id
for that reason, so compose can handle moves/reorders correctly.
s

semoro

04/11/2020, 2:06 PM
Isn’t it possible to detect reordering?
Like tell Compose that it should recompose RemovalArea once child changed?
z

Zach Klippenstein (he/him) [MOD]

04/11/2020, 2:15 PM
I was replying to your question "previously occupied slot for deleted element became used by next one, without reset of state" - this is exactly what
@Pivotal
is for, instead of just treating the removal as the composable parameters changing and reusing the slots/states from the deleted item, compose can see that they were actually removed, and the slots/state for the subsequent item in the list are effectively moved back up to fill the gap, preserving the state.
You shouldn't need to do anything special to handle reordering other than using that annotation, compose will handle it all for you.
It's also possible I misunderstood the issue you are having completely, in which case sorry for the noise.
s

semoro

04/11/2020, 2:17 PM
So it is impossible to get rid of
id
like parameters in such case?
z

Zach Klippenstein (he/him) [MOD]

04/11/2020, 2:38 PM
I don't think so, you need
id
here for the same reason RecyclerView does to correctly handle moves (
DiffUtil
distinguishes between content changes and "item identity" changes) - the system needs to have some concept of "which" item an item is for the concept of "move" to even make sense.
AdapterList
and the
Crossfade
composable make use of something like your
id
(they call it a
key
).
s

semoro

04/11/2020, 2:44 PM
Got it, thank you for clarification 🙂
z

Zach Klippenstein (he/him) [MOD]

04/11/2020, 2:49 PM
The pivotal stuff is a bit of a mind-bender but really useful for these cases where you're looping over a list, since for it to work the composables still have to be in the same "place" in the composition (ie in the source code, basically). https://developer.android.com/reference/kotlin/androidx/compose/Pivotal
Crossfade
uses the
key
function which is just a convenience if you don't already have a custom composable wrapping your children.
s

semoro

04/11/2020, 2:52 PM
I’ve made
id
parameter
Pivotal
and on removal of first item in list application hangs 😞 (ANR)
key
works althrough
👍 1
z

Zach Klippenstein (he/him) [MOD]

04/11/2020, 2:55 PM
I haven't hit that, definitely sounds like a bug - need a real compose dev to take a look 😅
I've been really only using
key
too actually but I wouldn't think they'd have different behavior 🤔
z

Zach Klippenstein (he/him) [MOD]

04/11/2020, 3:48 PM
That's the one that ANRs right?
👌 1
2 Views