On Tuesday, March 29, 2016 at 7:13:39 AM UTC+11, Luke Horton wrote: > Why does the re-frame framework restrict a 1:1 between dispatches and > handlers? > > At first I found it a little weird. I can think of lots of realistic cases > where: > > ``` > some event happens -> module a responds; module b responds; > ``` > > Then I thought... well, if one module has a handler that changes the app-db, > every other module only needs to subscribe to the same query, and they won't > *need* to also handle that event, it will happen reactively: > > ``` > some event -> module a responds (change db value) -> module b reacts to > change; > ``` > > But then I remembered that very frequently I need to handle this behavior: > > some event -> module a responds (starts fetching new data) ... eventually > updates db; > > Which I can't seem to fit into the paradigm of 1:1 handler to event. > > If we only have a 1-handler per event restriction, how can I also have: > > some event -> capture event in module a (start fetching new data); ??? ; > capture event in module b (start fetching a different set of data); > > Receiving the data would be relatively straightforward ... dispatch separate > events (from a receiving chan) for [:a-data] and [:b-data], but how we > implement in a decoupled manner the initial "go get data" across different > modules is lost on me. > > Any suggestions / patterns for solving this would be helpful.
At one point, I certainly considered allowing multiple handlers for events but I decided to put off implementing it until such time as I had a real need for it. But then, somehow over time, I just never *actually* needed it. It only ever stayed as a conceptual "I might need that one day" requirement. As a result, these days, born out of experience, I'm pretty sure it isn't generally necessary - and we write large, complex apps. If you were to implement it, you'd have to be careful of "Glitches" (google for FRP and glitches). You'd also have a tougher time with figwheel and reloading handlers. So you'd have to be careful your weren't paying a high price for something that you didn't end up using that much. I tried to position the reference implementation of re-frame in the "Goldilocks zone" for reactivity. But the chosen implementation is, of course, simply one point in the design space. BTW, do you have an OO background? Your talk of code firing in module a and module b, and then async channels, etc, gave me the sense of someone trying to understand re-frame through a "message passing" mindset. I think, once you get into it, that might drop away a bit. -- Mike -- 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.
