What do you mean by multiple of them? All submissions that happen while you hold the ui thread are executed together

Hmm I guess so. What about when the set-value! call is inside a callback function? The value of foo might be stale when the set-value! is called.

Isn't that why react's setState accepts an updater function?

@U0CKQ19AQ, Also, I think this is the same reason m/toggle! exists, right? Because (m/set-value! this :foo (not foo) is incorrect.

Maybe we can let set-value! accept an updater function in place of a value?

After reading the com.fulcrologic.fulcro.mutations namespace I think I know why m/set-value! cannot have a version like react's setState with updater function -- because in the end the value is set through a mutation set-props, and mutation arguments cannot be a function.

I guess that's also why there's m/raw-update-value! which sort of does what I want, but strangely asking for that current-props which wasn't asked in m/set-value!. The reason m/raw-update-value! has to ask for current-props is because, unlike the mutation set-props, it does not have access to the ref. (Although I don't see why you can't figure out ref from app which is typically this)

Also, m/raw-update-value! can not be used in a fixed-ident component, since it cannot figure out the ident from the props.

I think you need to show the code of what you're trying to do currently, instead of asking a generic question with no example.