I'm familiar with re-frame and have used it. The re-frame model works very well and I like it a lot.
This conversation was started over a year ago, before re-frame existed and before Om had ref cursors. The story now is quite different (for both Reagent and Om). On Sun, 19 Jul 2015 at 06:14 Kurt Mueller <kurtronaldmuel...@gmail.com> wrote: > On Wednesday, April 9, 2014 at 6:33:31 AM UTC-4, Daniel Kersten wrote: > > Hi, > > > > > > I'm trying to figure out the best way of structuring complex > applications in Om and I've hit a bit of a brick wall that I'm hoping > someone can help me with. > > > > > > > > > > I like the concept of cursors - narrow down the application state to > what the individual components actually need and allow them to read and > modify only that. > > > > > > The problem I'm having is that I don't know how to structure my state so > that the correct components have access to everything they need. Its easy > if each component only requires a strict subset of its parent, which is > often the case, but not always. I've hit a scenario where a component needs > access to two very different branches of the app state and I'm not sure how > to pass it to the component that needs it. > > > > > > > > > > As a (contrived) example, imagine you had an app for displaying orders > in an online store and the application state is something like this: > > > > > > (def app-state (atom {:items [{:type "book" :price 123} {:type "cd" > :price 200}] > > > > > > :orders [{:date xxx :type "book" :count 3} {:date > yyy :type "cd" :count 1}] > > :filter "book"})) > > > > > > > > > > You can imagine that in a real application the :items and :orders > branches may be much deeper. > > > > > > Lets say I now have two components, one displaying the items (so it is > passed a cursor with path [:items]) and one displaying the orders (so it is > passed a cursor with path [:orders]). What if I now only want to display > items and orders where the type matches the filter? > > > > > > > > > > I have a few options: > > Restructure the app state in a way that gives each component access to > what it needs. This is not ideal as it means that I'm modelling my state > after how its being rendered rather than how its being processed and makes > it very application specific. > > > > I can propagate the additional values down the component tree (eg using > the :state parameter to build), but this means that every other component > before the one that consumes it must now do additional work that it > shouldn't need to know about (couples the parent components too tightly to > the child one) > > > > Similarly, passing it in opts is not ideal as it has the same issue as > #2, with the added caveat that the component also won't rerender on > change.I can store the value in component local state and update it through > a core.async channel. This works well in the example above, where one or > two simple values need to be communicated, but gets unruly when the > application is more complex. > > > > I can pass the entire app state to each component (perhaps trough shared > state) and use transformation functions (similar to what Sean Grove did in > his recent slides) to transform the state into a local view for each > component. This means each component gets to select exactly what it needs > to access without worrying about what comes before or after it in the > hierarchy, but then you lose the benefit of cursors and automatic > re-rendering when something changes. > > > > > > > > > > I'm sure I'm missing something! > > > > > > Any tips appreciated. > > > > > > Dan. > > Hi Daniel, > > I haven't been using Om but I have been using re-frame. In re-frame, you > create "subscriptions" where you specify what parts of the app state db > you're interested in. Then, in your views, your component is composed of > these subscriptions. > > I find this paradigm makes it really easy for my components to be able to > listen for state changes even if the the state change is occurring in > different places in the overall state data structure. > > -- > 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 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 clojurescript+unsubscr...@googlegroups.com. To post to this group, send email to clojurescript@googlegroups.com. Visit this group at http://groups.google.com/group/clojurescript.