Fork me on GitHub
#om
<
2016-05-04
>
abtv11:05:37

Some time ago I asked about composing 2 queries in a parent component. There is the code: https://github.com/abtv/tech-radar/blob/master/src/cljs/tech-radar/ui/root_component.cljs

abtv11:05:03

`[{:settings ~(reduce conj (om/get-query NavBar) (om/get-query TopicView))} :trends :topics :current-screen :current-topic]

anmonteiro11:05:22

@abtv: that just won’t work

anmonteiro11:05:16

if your NavBar and TopicView components need to present different info, it’s best to make a union query

abtv11:05:37

@anmonteiro: like this one: static om/IQuery (query [this] (zipmap [:dashboard/post :dashboard/photo :dashboard/graphic] (map #(conj % :favorites) [(om/get-query Post) (om/get-query Photo) (om/get-query Graphic)]))) ?

abtv11:05:18

My 2 queries can have some common fields and some different

anmonteiro11:05:04

@abtv: yes. that works

anmonteiro11:05:26

but concatenating queries together like you did will break stuff

abtv11:05:22

Looks like I need to implement om/Ident, right? @anmonteiro

anmonteiro11:05:41

Union queries need an ident implementation, yes

abtv11:05:01

ah, it will change state accordingly (to normalize it)

anmonteiro11:05:01

you can also solve your problem by having 2 different join keys

anmonteiro11:05:27

[{:settings (om/get-query NavBar)} {:other-settings (om/get-query TopicView)}]

abtv11:05:18

but it means that I need to change state, no? it expects to have :settings and :other-settings key inside my state map

devth13:05:56

when implementing a read, does that read need to satisfy the entire query, or can it delegate sub-parts of the query to other readers? and if so, how–does it need to call parser?

hueyp15:05:52

@devth: I’d say db->tree with a default db and then a recursive parser are two common strategies

griff16:05:26

Is there a way to force root to rerender all components on figwheel reload?

kendall.buchanan16:05:56

@devth: read satisfies a single item in your query. But, that single item could be a single key, or a link to a subquery, in which case you use the parser to work recursively, to other read implementations for other keys. Not sure that helps much – you’re working through the most difficult part of om.next’s learning phase.

adamfrey18:05:44

@griff: to completely re-render all components you can call om/add-root! again on your on-load callback. That will blow away any component local state

gaye19:05:30

Hi om! I am totally new to Clojure (but have a good bit of experience with React and decided to give om.next a try). I ran into an issue with getting initial state to a non-root component and filed https://github.com/omcljs/om/issues/674 and made a tiny test case here https://github.com/gaye/om-issue-674. @anmonteiro mentioned that my component query here https://github.com/gaye/om-issue-674/blob/master/src/issue674/component/input.cljs#L7 doesn't "compose to the root". Can someone help me understand what exactly I'm supposed to pass to query? This was particularly confusing because the input does get state appropriately after I start sending key events to it. Thanks for your help and @anmonteiro for inviting me here!

mattyulrich22:05:22

Hi all - I feel like I keep asking the same Om.Next questions over and over. I’m still trying to better understand how to bridge between the information I get in my app-state from the server and the various queries and components. I’ve created a gist with an idea of my problem; is anyone available to try and help me better understand?

mattyulrich22:05:38

Really, my issue is moving from the “target-app-state” through the read functions to the component queries. Do I need Ident functions to restructure the app-state or should I just build read functions to break apart the app state as I get it from the server?

mattyulrich22:05:26

To be clear, the above listed gist is not the complete code and therefore will not run. It’s just the basics of where I find myself most confused - how should my queries map through the read functions over the app-state?

cjmurphy23:05:55

@gaye: Your root component there doesn't have a query. What it needs to have is all the queries of the subcomponents, but as joins. Data comes in from the root, thus you have to have joins for all your subcomponents there. I recommend reading the Kanban demo. In it the root has joins that are for more than just the immediate subcomponents, for even components one layer further down (lanes iirc).

cjmurphy23:05:49

@mattyulrich: your components need idents in order for your initial data to become normalized. You can @my-reconciler to check for yourself that the job has been done correctly. All your reads should look the same. I recommend starting with working code and just (pprint @my-reconciler) to see what default db format should look like. Again the kanban demo: https://github.com/Jannis/om-next-kanban-demo