thanks

I cant' find out how to have 2 components which show the same data, but have different operations. I have a counter and 2 components. InnerView component shows a value of the counter and can increment the value. SmallView component shows the same value of the counter and can decrement_ the value. What is the idiomatic approach to implement it? I have the following, but it fails to update one of components when I call transact!.

Can I create things like this?: (query [this] [{:settings (om/get-query InnerView)} {:settings (om/get-query SmallView)}])

@abtv: I would also like to know that I am doing something like this:

`[({:forms/current ~(om/get-query ColumnSelection)} {:form/type :form.type/company})
  ({:forms/current ~(om/get-query FilterBar)} {:form/type :form.type/company})]

@mitchelkuijpers: why do we need lists there inside a query vector?

@abtv: to give the query the parameter :form/type

@abtv: the same thing you do with mutations

is this a query vector or mutation?

@mitchelkuijpers: join queries are hydrated by the parser into maps

and you can’t have repeated keys in a map

Aha that makes sense

so you shouldn’t have repeated keys in a query

I’m pretty sure you would never write a query like this: [:foo :foo]

can I just conjoin 2 subqueries? @anmonteiro

@abtv: I’m not sure I understand, but I’m going to cautiously say “no"

@anmonteiro: could you say how to implement what I'm trying to do (the code above)?

ah, I hadn’t looked

@abtv: seems like the simplest case would be to have 1 component

with a query like [:value :label: ]

For me that isn’t really an option.. but maybe I am going wrong about this

you could also pass the label as a computed prop

no, I'm trying to understand how to implement it with 2 components. I have a problem and trying to solve it with the simple example @anmonteiro

this one: https://clojurians.slack.com/files/abtv/F15BWK00G/-.clj @anmonteiro

maybe your example doesn’t clearly illustrate the real problem you’re having

I’d definitely pass the transaction as a computed prop

and have only 1 component in that case

which could be reused for the 2 operations

I see. Do you know some useful and simple examples of Om.Next (not untangled)?

not from the top of my head

there are some links in the om wiki

I saw them looks pretty complex

people find the om-tutorial pretty useful too

https://awkay.github.com/om-tutorial

>I’d definitely pass the transaction as a computed prop Like this one: https://github.com/Jannis/om-next-kanban-demo/blob/master/src/kanban/app.cljs ? @anmonteiro

is it an idiomatic approach? ^

yes

@abtv: I’ve actually got a simple example of what I meant

https://github.com/anmonteiro/devcards-om-next/blob/master/src/devcards/devcards_om_next/devcards/core.cljs#L67-L108

something like this

is how I’ve solved the problem of a counter that increments and decrements

it’s a different context, though

and only meant to be looked as an example

I see, great thanks @anmonteiro

Thank you btw @anmonteiro i fixed it with some computed props now. This actually feels cleaner.

While it works with computed props I still can't understand why do I need to call transact! on parent, not child? If I call it on a child component I receive the error: #error {:message "No queries exist for component path (om-next-starter-kit.core/OuterView om-next-starter-kit.core/InnerView)", :data {:type :om.next/no-queries}}

And another question: if I have settings page with 2 components how to combine queries from each component to make a join on settings? It feels like I need something like {:settings (something-here (om/get-query Component1) (om/get-query Component2))}. Right now I just pass [:settings] , but this is equivalent to [{:settings [*]}] , right? Or Om.Next can do detect it automatically?

Eventually I settled down on this: (query [this] `[{:settings ~(reduce conj (om/get-query InnerView) (om/get-query SmallView))}])

but it's possible to have duplicates with this approach

I have a question regarding links from the Thinking With Links! tutorial on the wiki. Should I expect a change on :current-user to trigger a render of the above component?