> 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
Hi Mike, That very well could be my problem. 2 years ago I wrote a custom event-driven architecture to serve a very data heavy application with some other special needs related to event sourcing. I'm also ~6 months into a redux-style architecture for another non-trivial workflow app. Maybe I just don't "get it", or maybe I'm not willing to "let go and trust the system". I have a huge hang-up around modularity, having been bitten in the past. Architectures such as redux really don't solve that modularity problem out of the box, and I suspect (correctly or not) re-frame might suffer the same fate. To me, message-passing at the top-most level between components (in the DDD sense, aggregate roots) is "the way" to maintain decoupling and reuse. I get nervous when I don't see any strategy for communicating between two completely independent pieces through a well-defined API (message passing or others). With respect to this concern, I wrote up a quick gh issue that may or may not prove helpful to re-frame: https://github.com/Day8/re-frame/issues/160 -- 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 clojurescript+unsubscr...@googlegroups.com. To post to this group, send email to clojurescript@googlegroups.com. Visit this group at https://groups.google.com/group/clojurescript.
