While Omchaya has some excellent bits, I definitely don't recommend using swap! over transact!. I hope that the community can continue to modify Omchaya to reflect collective best practice.
David On Sat, Mar 29, 2014 at 10:53 AM, Rob Knight <[email protected] > wrote: > On Saturday, 29 March 2014 09:22:17 UTC, Daniel Bell wrote: > > So, I figured it out, and wrote a blog post on why this is a terrible > idea: > > > > http://roninhacker.wordpress.com/2014/03/29/how-to-build-stuff-with-om/ > > I've been looking at this myself and, like you, I've looked at Omchaya as > an example of how to build a non-toy UI. However, a couple of things > troubled me about Omchaya, though this might be because I'm not > knowledgeable enough about Om yet. > > The main thing that throws me is that Omchaya doesn't use transact! or > update! at all. Omchaya's components don't write to the application state, > they just put messages on to channels, which are read by a central > controller. This controller then calls handlers (via multimethods), and > these use swap! to update the application state. This actually reminds me > of the central event aggregator that I've seen used in complex Backbone > apps. > > Right now I am not sure why the components don't just update the state > using transact!, skipping the whole controller piece, which feels like it > would make the components more reusable - they don't need to know about > anything outside of the component itself, except for the state cursor. If > the component needs to communicate with the outside world, it can trigger a > state change via transact! and can even attach metadata via the tag > parameter. If the application needs to do any post-update stuff after a > state change (which Omchaya does), this can be achieved using :tx-listen > when setting up the Om root. > > On the flip side, channels are great and Omchaya's approach does achieve > two important things: it makes event handlers incredibly simple (just post > an event to a channel) and it centralises all state-change code, which > might make the program easier to reason about and might make it easier to > do things like logging or aspect-oriented-ish stuff around state changes. > I just wonder if Om doesn't already provide mechanisms to do that kind of > thing via transactions and :tx-listen. > > I'm not sure that either way is necessarily right or wrong, and it's > possible that my approach would not work for reasons that I'm currently > ignorant of, so please see it as a conjecture that I am hoping to have > refuted or validated by people who know more than I do! > > -- > 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 http://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 http://groups.google.com/group/clojurescript.
