Sounds right to me. At the UI (in a component) it makes sense for parents to have knowledge of children but not visa-versa. Especially so if the child can have other parents. Once you are at the mutation level however there's global scope. And with the default (keyframe) renderer there are no rendering issues no matter where the mutation is triggered from - i.e. it doesn't matter where transact! is called.

I'm a little unclear as to the distinction between stuff happening at the UI level vs. in a mutation. As far as I've made it through the guides, all the mutations are triggered from within a component - something like an onclick event on a button. If that's the way it is, mutations are generally all within UI. Is it just that when you are in a defsc form, you're limited to whatever is in that particular scope, but once you call transact! within a defsc form, you're in a defmutation form and have access to the global scope?

If it's not the wrong approach, it makes sense for cards to be dealt from the deck, placing the deal-card mutation on the Deck component. Then, within the mutation, I could query for all the player ids and deal to each of them. It's either this way, or going to a common parent node and dealing from there, since that component would have both the player ids and the deck.

When your code is in a client defmutation it has access to the state atom, so all state from all components is available using get-in . Here your component instances are represented by idents. Consider this example from the developer's guide: (conj category-ident :category/items). (I just looked for conj because it is very common to get to a location using using an ident then an attribute (that comes from a defsc). Any location is three things away.