Hi both, Thanks Sean for the reference. I had looked at that before, which may well have coloured my thinking. My initial thoughts are that yes, Flux is a way to go but om's "world in an atom" makes the store concept redundant, or rather is the implementation of the stores.
They are also pushing for ControllerViews, which is what my initial question was pondering the wisdom of, so that is encouraging. Will be interesting to see how this scales out in practice. I have already come across a few situations where I want to have a co-ordinated update to many bits of the app-state which doesn't naturally fit into any particular view, but that can be done up-stream of changes to the app-state without issue. One example in question is I have a triStateTree. The rules are a parent is selected IFF all the children are selected. I have a triStateTree view which takes in a node hierarchy and selected-ids. When the node hierarchy changes I want to ensure the selected-ids are still correct (imagine a new child was added to a selected parent, that child should be selected. I could put this into the view, but there doesn't seem to be a nice place to update props/app-state before rendering that takes effect immediately (unless I miss something there) and it doesn't really sit well being in the view (views shouldn't change state etc.). A listener to the nodes changing and broadcasting that to anybody who cares feels much nicer. Thanks again. On 26 November 2014 at 18:59, Sean Johnson <[email protected]> wrote: > 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 a topic in the Google > Groups "ClojureScript" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/clojurescript/9rKpMCdpOF4/unsubscribe. > To unsubscribe from this group and all its topics, 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.
