how can we sort a SnapshotList. is it better just to create a new list i supposed. notification spam ?

Copy, sort, clear and addAll.

If you're doing it on the main thread you don't need to create an explicit snapshot, you can just sort the list in-place. If you're doing it off the main thread, you can wrap in a

Snapshot.withMutableSnapshot {}

.

ya, main thread, so i can just clear addAll and it wont trigger multiple notifications?

Change notifications are not actually sent when a snapshot state object is changed, they're only sent when a snapshot is committed, regardless of how many times an object was changed in that snapshot. If you're on the main thread and not in a composition, the snapshot in question is the global snapshot, which gets committed just before the next frame

Change notifications are not actually sent when a snapshot state object is changed, they're only sent when a snapshot is committed

oh hm. TIL

What if multithreaded recomposition was working? Would running on the main thread ensure that the state won't be commited during the sorting? 🤔 Or will SnapshotState not be impacted by multithreaded recomposition because that will only impact the actual calculation of the UI? Does the question even makes sense? 😅 It's not really important, I am just curious 😅

If you’re in a composition then the compose runtime is already ensuring you’re in a snapshot, whether that’s on the main thread or in the future when multithreaded composition is working

ya, thanks. So it would be something like this:

val list = mutableStateListOf<Unit>()
Snapshot.withMutableSnapshot {
    list.sortBy {  } ..
}

?

oh thats really cool. I've definitely had some sort operations, i.e. sort, clear list, add new sorted list to list. Seems like I should have wrapped all of that in a Snapshot.withMutableSnapshot { }

If you are using the main thread, dont bother 😛 otherwise ya

Oh yeah. I guess I'm using the main thread typically i do this with a firebase observable that I observe in my VM. Something like this

VM {
  init {
    viewModelScope.launch {
      firestore.observeTodoItems {
        val sorted = it.sort()
        state.todos.clear()
        state.todos.addAll(sorted)
      }
    }
  }
}

Sorry for returning to this thread after two weeks but I keep thinking about this 😅 I am preparing meetup talk about Snapshots and would love to talk about this. But I can't find good code example that will show why it's bad idea to change state from different (non-Main) thread without

Snapshot.withMutableSnapshot { ... }

.

Probably the usual race condition stress test should work: two threads running tight loops that modify a single state with multiple read+write ops.

Yes, this is some extreme example that would show the benefits of Snapshots but previously in this thread you wrote

.... If you're doing it off the main thread, you can wrap in a

Snapshot.withMutableSnapshot {}

.

when talking about sorting a list in place. I thought the reason is that the global snapshot could be advanced during this operation resulting in frame that has only part of the list sorted. Is that not the reason? If it is, how can I show it in an example? Because while your example show the benefits of Snapshots, it's usually not this extreme in real world scenario. I've been reading about and playing with snapshots (in Compose UI) for a while but I feel like something is still not clicking for me. You know the feeling, like I'm missing something simple and obvious but I am just overthinking it.

That tends to be how race conditions like this work - they seem unlikely but when they happen they are extremely hard to find and debug

@Zach Klippenstein (he/him) [MOD] how merge policy for this case should looks like? Following one still provides weird results

val counter = mutableStateOf(0, object : SnapshotMutationPolicy<Int> {

override fun equivalent(a: Int, b: Int) = false // comparison make no sense

override fun merge(previous: Int, current: Int, applied: Int): Int {

return current + (applied - previous)

}

})