I was working on an app last year where I separated events that are triggered in the components (I called them signals) and events handled by handlers (I called these events as these are the normal re-frame events) and then you could map signals to events. By default, a signal was the event of the same name, but you could override this and connect them any way you wanted. A signal could be connected to multiple events and multiple signals could be mapped to the same event.
In a way, the events were basically just slot names in a lightweight signals and slots system. Of course this didn't handle ordering but like you, my handlers always accessed different state, so this wasn't a problem. This is probably a overkill unless this is a common use case. I implemented it by having an emit function that would look up the connections and then dispatch the correct re-frame events. Then my components always used that emit function and not re-frame's dispatch function. Which technique you use depends on your goals and needs, I guess... I don't think one way is necessarily better than the other. On Tue 29 Mar 2016 at 21:11, Luke Horton <[email protected]> wrote: > 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. > -- 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.
