Good point Daniel. As you mentioned, because I'm dealing with unrelated state, I didn't have to think about this issue.
I can imagine a convenient queuing system that captures everyone who wants to make a change, attempts the change, and throws if two changes attempt to modify the same piece of state... or some sort of explicit priority system (yuck). I wonder if there is a better way to achieve my end-goal through a different means that's more in-line with the re-frame philosophy? In my naivete I would attempt solving the problem this way: [:button-clicked] event top-level handler captures event, sets state [:clicked true] component A, B both detect [:clicked ] flag change, do some dispatch of their own? A, B handlers capture their respective dispatches This seems awful for a few reasons. Namely the "circular dispatching" that make things really hard to debug/reason about. Might you suggest another way? I could conceive of a "top level" component holding onto A and B and being the coordinator between the two... when [:button-clicked] shows up, it knows about A and B and how to get the data for both. The problem with this approach is it's not very modular, and doesn't scale well. How could you have a handful of A and B components smattered about, or a handful of top-level components, for that matter? Get's ugly quick. -- Note that posts from new members are moderated - please be patient with your first post. --- You received this message because you are subscribed to the Google Groups "ClojureScript" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/clojurescript.
