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.
