https://kotlinlang.org logo
Join Slack
Powered by
I’m trying to implement list with animated swipe r...
# compose
s
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
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
I’ll update it once I’ll fix that problem than 🙂
Could also share swipe handler like in GMail items
z
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
Isn’t it possible to detect reordering?
Like tell Compose that it should recompose RemovalArea once child changed?
z
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
So it is impossible to get rid of 
id
like parameters in such case?
z
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
Got it, thank you for clarification 🙂
z
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
I’ve made 
id
parameter 
Pivotal
and on removal of first item in list application hangs 😞 (ANR)
key
works althrough
👍 1
z
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 🤔
s
z
That's the one that ANRs right?
👌 1
s
2 Views
Open in Slack
PreviousNext
Powered by