<https://medium.com/@behzodhalil/recomposition-is-...

# feed

[Behzod]

https://medium.com/@behzodhalil/recomposition-is-not-a-bug-you-are-5d736f65c8b9

[Stefan Oltmann]

Catchy title 😄

The article is a good summary of best practices 👍 🙂

[kqr]

I am not sure I understand. why wouldn't mutating in place make equals return false?

Important: Compose uses equals() comparison for keys, not identity comparison. This means if you pass a List<String> as a key, it compares the list contents. So mutating a list in-place won't invalidate the cache—you need a new list instance.

[Indra]

After looking at the source code of SlotTable, in my opinion, the reason why in-place mutation on the List<String> would not invalidate the cache is because the content mutation made into, say, the passed List<String>, would also gets reflected into the "remembered" value inside the SlotTable because Compose will not make a copy of the List and instead only stored a reference to the same instance.

I haven't completely understand the "big picture" of the SlotTable class usage and things inside the Composer.kt file but, to my understanding it would behave similarly to this sample in Kotlin Playground:

<https://pl.kotl.in/xCKSmaoC->

[Indra]

Also, technically we can make a copy, by doing something like, for example in the Kotlin Playground link before change this simpleSlot.addSample(originalList) line into simpleSlot.addSample(originalList.toList())

Then I think we can use a List<String> as a key for the remember part. because then the one that gets remembered is a fresh copy. Kind of like what happen in Swift language by default if I'm not wrong.

[kqr]

makes sense, but I did not understand it from article. I understood "it compares the list contents" as it should not be equal when content has changed