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?

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 👍

I’ll update it once I’ll fix that problem than 🙂

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.

Isn’t it possible to detect reordering?

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.

So it is impossible to get rid of

id

like parameters in such case?

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

).

Got it, thank you for clarification 🙂

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

I’ve made

id

parameter

Pivotal

and on removal of first item in list application hangs 😞 (ANR)

I haven't hit that, definitely sounds like a bug - need a real compose dev to take a look 😅

That's the one that ANRs right?

No ANR: https://gist.github.com/semoro/ea7c07cf3bcbd3bc4cbc4729b82b4140#file-composeremovalarea-kt-L65