Colin, I have no experience with large scale Om apps (hope to soon), but do with large scale React apps in JavaScript. The thing you maybe intuiting is the pattern used to apply React in the large called Flux.
Details here: http://facebook.github.io/flux/docs/overview.html#content In addition to the React/Om views, Flux adds the concept of dispatchers and stores to help organize the unidirectional data flow in large React apps. I've put off thinking hard about how and if and how directly Flux applies to Om, so I can't offer much guidance at this point. But it seems it's something to look at and think about. Maybe there is the same or a similar pattern needed for applying Om in the large? Not sure yet. Cheers, Sean > I have a non-trivial om app which has discrete areas of functionality and I > am um'ing and arr'ing about how to structure it. > > My hackathon has produced a number of fairly course grained components which > represent each "page" in the app. These components create and manage the > channels which are passed to finer grained components (e.g. trees and > tables), and update app-state in response to messages from those finer > grained components. > > In a more "traditional" app I would have separate controllers for this and > have a central event bus upon which the components put messages. The fine > grained components do this but these large components act as the controllers. > > I can't really see where I am going to go wrong with this approach, and > having coarse things which happen to be om/components but encapsulate a large > discrete chunk of functionality is nice. > > But then I keep waking up thinking "yeah, let's get those controllers > written" and I can't decide if it is just legacy thinking pushing me or > intuition which I should pay attention to :). > > To be clear, imagine I have a menu with page1, page2 and page3. In app-state > I have {:page-1 {..} :page-2 {..} :page-3 {..} :reference-data {..}}. > page-1.cljs *is* page-1 and will assemble a number of components and lay them > out. It consumes (:page-1 app-state). Same for page-2 and so on. There are no > separate controllers. The only other bit is some machinery around > sente/message passing to the server and navigation. > > What lessons have you all learnt - do you have separate controllers and keep > the om/components strictly read-only? > > Who handles the "branch-expanded" event when the user expands a branch in the > generic tree we have all written :)? The tree component, the top-level > containing component or a separate controller? > > Thanks! -- 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.
