I've been silent, but I wanted to thank you for these changes. I believe these changes will work great. I am still trying to understand the difference between the two approaches, but I am still pretty new to Clojure. Thanks again!
On Sunday, October 5, 2014 7:45:26 AM UTC-6, David Nolen wrote: > Ian's NativeStore looks an interesting approach to the problem. > There's also some new work in progress in master, the examples > `two-lists` and `refs` if you are willing to spend some time reading > uncommented code. Lengthier explanations are planned. > > David > > On Sun, Oct 5, 2014 at 5:23 AM, Viksit Gaur <[email protected]> wrote: > > Hello all, > > > > Any updates on this issue in terms of - how do I access different parts of > > the app state from different locations? > > > > Thanks! > > > > On Wednesday, April 9, 2014 3:33:31 AM UTC-7, 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. > > > > -- > > 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.
