A modern programming language that makes developers happier.

kotlinlang

I do want to filter a SnapshotStateList and than use the filtered list in a LazyColumn. How can i do it?
Using this code does not work because it does not detect changes in the list and do not filter the list again:
```val list = remember(snapshotStateList) {
    snapshotStateList.filter { removed.contains(it).not() }
}```

As a workaround following code would work but only if the size of the list changes:
```val list = remember(snapshotStateList.size) {
    snapshotStateList.filter { removed.contains(it).not() }
}```

Not at all related but I'd go for `it !in removed`

Hmm, maybe something like: 
```val filteredList by remember(snapshotStateList, removed) { derivedStateOf { snapshotStateList.filter { it !in removed } }
```
 ?

Yes that works. Thank you <@UJBKXD0HH>
But i do not really understand why this works.

`derivedStateOf` is kind of like `mutableStateOf`, except it returns a read-only snapshot `State&lt;T&gt;` that always contains the latest value of the lambda expression it was constructed with. It caches the result of this computation. If the derived state block reads other snapshot state, the derived state object will invalidate its cache whenever the state it had to read changes.

snapshotStateList is this snapshot state object it reads, so any time snapshotStateList's contents change, it invalidates the derived state.

Then we `remember` that derived state object and use `by` property delegation just like we do with mutableStateOf in composition. We use the snapshot state list and the removed list as remember keys, so we create a new derived state object if we change the whole lists it's based on.

Is original example doesn't work because `snapshotStateList` is mutable, and when SlotTable compares remembered value with new value when `snapshotStateList` changes, it sees no difference, because it's the same object?

yep. (It also doesn't consider the `removed` collection changing.)

Wow, for some reason I assumed `derivedStateOf` didn't need to be remembered. TIL.

so the remember is just in case the referenced object changes right?

Hmm, I'm starting to question <@UJBKXD0HH>'s use of `removed` (and maybe `snapshotStateList`) in the `remember` keys, shouldn't `derivedStateOf` handle that already?

The `derivedStateOf` lambda closes over the collection instances of `snapshotStateList` and `removed`. If the actual collection instances change, we need to create a new `derivedStateOf` to observe those new collections.

All of the above therefore also presumes that `removed` is either another snapshot state list where the derivedStateOf can observe changes to it or immutable (so that the remember keys will result in a new derived state object if it does change)