Fork me on GitHub
#om
<
2017-01-08
>
ag00:01:15

@anmonteiro I guess my example is too trivial, what if the query has some nested subqueries, etc?

nha01:01:07

If a Counter component works fine in isolation (mounted on a div as seen on many tutorials), but fails when rendered from the render method of a Root component (only after a transaction), what should I put in my Root component query?

danielstockton09:01:15

(om/get-query CounterComponent) @nha

danielstockton09:01:34

the parent component should contain the queries of all the children and compose all the way up to root

nha15:01:05

@danielstockton and then pass it down to the component manually? that seems to work 🙂 Not sure yet how I can make that work with routing though

danielstockton16:01:59

Yep, principle is the same with routing, shouldn't make a difference.

nha17:01:07

I am missing something: why is it showing the values after I click on it? (ie. not the initial state)

danielstockton17:01:01

i wouldnt expect it to show anything, you're not passing anything to counter factory

danielstockton17:01:49

[:current-route :something-else {:counter ~(om/get-query Counter)}] is the query you want in your Root component

danielstockton17:01:02

then get counter and pass it to the counter component

danielstockton17:01:25

`[:current-route :something-else {:counter ~(om/get-query Counter)}]

danielstockton17:01:54

don't forgot to quote it ^^

iconara17:01:20

sorry to hijack the conversation, but why does it need to be quoted?

iconara17:01:01

the only non-static part of that expression is unquoted anyway, so what am I missing (I've seen this in examples and not understood)

danielstockton17:01:06

@iconara you're totally right, i don't think you do actually

iconara17:01:49

@danielstockton ok, thanks for confirming that I'm not crazy 🙂

danielstockton17:01:39

i might be wrong, maybe someone else can confirm

nha18:01:01

ok, calling it like that ((om/factory Counter) (get (om/props this) [:count])) works.

nha18:01:24

I will have to write some logic with routing though (since the component to render changes with the route)

danielstockton18:01:06

routing is basically a root component with a union query of all the pages, switching the child component and what gets passed to it

danielstockton18:01:32

you shouldnt have to make any adjustments to what you've done here

danielstockton18:01:51

the Root you defined here will be a child of the routing component, which is the real root

nha18:01:08

Ok I have to learn more about union queries 🙂 thanks !

danielstockton18:01:49

compassus is a lib that does it for you and hides most of the gory details

nha18:01:38

I heard about it ^^ I would like to understand a bit more though before using it. I don't understand it's tradeoffs. I am not sure also why it has to wrapt the call to om in compassus/application instead of providing a RouterComponent (for instance) and if it would prevent me from using things that also wrap some om calls (like untangled, but there could be something else again in the future).

danielstockton19:01:29

its definitely worthwhile understanding how it works and knowing you can do it yourself

sova-soars-the-sora22:01:54

@jfntn did you figure out your issue? you have tempIDs client-side and want to merge-with data server-side?

jfntn22:01:39

@sova correct. We have that working fine for mutations, mostly because we use datomic so there is little work required. For reads things get a bit more involved and though I have it working now I rely on a rather complicated custom merge function

jfntn22:01:02

The logic is basically to check if the app-state contains an ident for the read key, and if it does add a :tempids map to the result and let om/default-merge do the heavy lifting

jfntn22:01:19

But that’s not super robust since it’ll only work on aggregate roots