Should we use `SideEffect` for atomicity on operat...

# compose

[Vsevolod Ganin]

Should we use SideEffect for atomicity on operation on local state? The doc is a bit unclear:

SideEffect can be used to apply side effects to objects managed by the composition that are not backed by snapshots so as not to leave those objects in an inconsistent state if the current composition operation fails.

So this applies also to snapshot-backed objects when we need to make atomic change on them, right?

[Adam Powell]

Can you describe the use case?

[Adam Powell]

Several changes to snapshot-backed objects can be made atomically by making those changes within a snapshot. The changes are not made visible to other threads until the snapshot is committed. Snapshot.withMutableSnapshot {} is one way to do this, but if you're making changes to snapshot-backed objects in a @Composable function you don't need to do this explicitly, because compose always performs composition in a mutable snapshot of its own.

[Vsevolod Ganin]

We can take Crossfade as an example. Inside you can see that there are consequent but not atomic ops on items

items.map …

items.clear()

keys.mapTo(items) …

Shouldn’t it wrapped with SideEffect?

[Vsevolod Ganin]

If composition fails after clear but before maptTo it is left inconsistent since targetChanged is already used, isn’t it?

[Adam Powell]

if composition fails then the composition snapshot will not be committed, so none of the changes will be reflected elsewhere

[Vsevolod Ganin]

Ahh, I see. Thanks