I have a `Column` of `Item`, for example like this...

# compose

[Alexander Maryanovsky]

I have a Column of Item, for example like this:

A2
C1
B2

with something like

@Composable
fun Item(letter: Char, index: Int){ ... }

Now each item belongs to a group, specified by the letter (A, B, C etc.) and has an index, specified by the number. The user can
1. Change the item’s index by selecting the item and pressing left/right. So, selecting “A2”, for example, and pressing right, changes the item to “A3". When this happens, I’m animating the Text using AnimatedContent so the “A3” slides in from the right and the “A2" slides out to the left. The animation runs when the new index is adjacent to the previous index.
2. Remove an item by selecting it and pressing “delete”.
Now, I have a problem. If the list is, for example

A1
A2
...

and the user deletes A1, the animation runs because as far as the 1st call to Item is concerned, what happened was the index `remember`ed by AnimatedContent changed from ‘1’ to ‘2’.
I would like to not have the animation run in this case.
If I key the Item with index then the animation doesn’t run even when it should.

[Alex Vanyo]

Using key is definitely the right track, but you will probably need to create some sort of unique id to use as the key to specify which items are “the same” that are being modified or deleted.

Here’s another way to look at it:
Let’s say I gave you this list before, and this list after.

Before:

A1
A2
A3
...

After:

A2
A3
A4
...

Just from looking at those two lists, there’s two possibilities:
Either A1 was deleted, or all of the items were incremented.

But just by looking at the before and after, there’s no way to know which happened, and that before and after view is all Compose knows as well. There needs to be some additional information used for tracking what happened.

[Alexander Maryanovsky]

Yes, unfortunately that's exactly the problem. The initial and final states are the same. Only the user action that triggered the change is different.

[Alex Vanyo]

Right, the information you have right now isn’t enough.
I’d try doing something like keeping a UUID.randomUUID() around with your items, and using that as your key. Removing an item would cause a UUID to be deleted, whereas updating an item would keep the old UUID, but with a new value.

[Alexander Maryanovsky]

That's going to be tough. The item list is the result on an external computation that exposes it via StateFlows.