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.

Reply via email to