Hello Everyone, I'm trying to apply a `snapShot` o...
# compose
r
Hello Everyone, I'm trying to apply a
snapShot
on button click but I keep running into a
snapshotApplyConflictException
z
What exactly are you trying to do? Besides apparently violating the snapshot rules, this seems extremely fishy to me. The conflict is probably happening because there’s a snapshot open during composition when you take your snapshot, but that snapshot gets applied on the next frame I think, and there could be any number of subsequent snapshots taken and applied before the click event so it seems extremely likely that there could be a conflict.
s
is there any real example of using snapshots? 🤔
k
What is snapshot
r
@Zach Klippenstein (he/him) [MOD] im trying to leverage the snapshop system as a way of rolling back changes in controls. more like an undo mechanism
z
Interesting idea, but I don't think snapshots are really designed for that. You can perhaps peek into a previous snapshot, but AFAIK you can't reset the current actual value of states from a snapshot. Also, since compose uses snapshots for all its state, i think this would also affect things like animation, making it impossible to animate between undo states, and it might have other weird side effects too.
👍 1
Snapshots are a low-level API that compose uses to track changes to state objects and makes access to those objects thread safe.
There's always a global snapshot open. Before every frame, the global snapshot is applied. When it's applied, Compose gets notified about any state objects that were changed since the last snapshot. It uses that list of changed states to calculate which composables need to be recomposed for the frame.
👍 2
s
Thank you for explaining this 👍
r
@Zach Klippenstein (he/him) [MOD] Thank you. It all makes sense to me now. Is there a way to defer recomposition? In flutter when you run
setState{ }
the whole block will be executed before the UI is rebuilt. Is there anything like that in compose?
z
Right now, Compose is all single-threaded, so any code that runs synchronously (e.g. in an event handler) will be all executed before the next composition pass/frame. Once Compose starts using multiple threads, I believe there’s still a guarantee that only composition will happen on threads other than the main thread, but things like event handlers will still always execute on the main thread so the same property should hold.
1