The idea behind IResolve is that many programs would like to get at information in the app-state without directly receiving it from a parent component as the parent component doesn't need it and shouldn't care.
David On Mon, Oct 6, 2014 at 1:02 PM, Viksit Gaur <[email protected]> wrote: > Thanks for the reply, David. > > On Sunday, October 5, 2014 6:45:26 AM UTC-7, David Nolen wrote: >> Ian's NativeStore looks an interesting approach to the problem. > > Ah will check it out in detail. > >> >> 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. >> > > Thanks for the pointer - could you talk about a starting point, about what > the thought there is with IResolve? > > Cheers > Viksit > >> >> >> David >> >> >> >> On Sun, Oct 5, 2014 at 5:23 AM, Viksit Gaur 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. -- 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.
