Fork me on GitHub
#om
<
2016-06-10
>
peeja00:06:03

In a send that's fetching a value for an ident, what sort of structure should I give the callback to get it to merge correctly?

noonian00:06:53

I think you want something like {[:thing/by-id :some-id] {:id :some-id, …}}

peeja00:06:39

@noonian: Hey, that works! Cheers!

peeja00:06:12

Ah, of course. I want to be returning it like the result of a query, not in the shape that it's normalized to in the db.

noonian00:06:10

I think this behavior depends on if you’ve overridden :merge-tree in your reconciler also. And if your app is more complex you might need to provide your own smarter merge function.

peeja00:06:06

Yeah, that makes sense

jasonjckn04:06:32

can I transact inside an :action ?

jasonjckn04:06:42

i just want to compose some transactions

hkjels07:06:18

When running a parser recursively, the data is keyed with it’s parent. How do I then select the right portion from a child-parser without mentioning the parent?

iwankaramazow09:06:16

You can modify the ast, if it's a remote you're talking about

jimmy11:06:50

hi guys, does any on experience with link query that instead of return just the key in link query, it returns the whole query as key. For example in my case:

;; query `[[:route/data ~'_]]
;; value returned in props {[:route/data _] {:_type :new}}
I expect it should be {:route/data {:_type :new}}, shouldn't it ?

cjmurphy11:06:59

That would go against the idea that whereever a key can go, a link can go instead. Also I think of both of them as indivisible. It would be inconsistent to make the request with a link and get back a key(word).

jimmy11:06:06

@cjmurphy: thanks for the response. How about the link in this example https://github.com/omcljs/om/wiki/Thinking-With-Links! . Does a link in a component with ident interpreted different than the one from component without ident ?

cjmurphy11:06:50

And thanks for reminding me about ~'_ - no wonder I've had so much trouble - forgotten you had to do that.

cjmurphy11:06:36

I wouldn't think so. Just using a link instead of a keyword in the query has no effect on the ident. The link isn't used in the ident in that example.

cjmurphy11:06:55

The great thing about links is that you can just put them in your state, then put them in different components all over the place. Good for information that isn't part of the tree.

cjmurphy11:06:52

i.e. information that wouldn

cjmurphy11:06:13

't have joins, and therefore wouldn't have idents.

jimmy11:06:34

yeah, link is very convenient. I might not explain things clearly, let's put the example above in comparison:

(defui Item ;; with ident
  static om/Ident
  (ident [_ {:keys [id]}]
    [:item/by-id id])
  static om/IQuery
  (query [_]
    '[:id :title [:current-user _]])
  Object
  (render [this]
    (let [{:keys [title current-user]} (om/props this)] ;; we can use current-user here instead of [:current-user _]
      (dom/li nil
        (dom/div nil title)
        (dom/div nil (:email current-user))))))

(defui Item ;;without ident
  static om/IQuery
  (query [_]
    '[[:current-user _]])
  Object
  (render [this]
    (let [{:keys [current-user] :as props} (om/props this)]
      (prn "value" (get props '[:current-user _]) ;; now the value is in [:current-user _]
    ))
I'm not sure this is normal, it looks a bit weird to me 😛 . That's my concern

cjmurphy11:06:41

I've always used links in components that have idents so never seen your without ident example before. Seems like an interesting quirk that will have an explanation 😛

jimmy11:06:43

yeah, it's true ... I find I do have some weirds way using om next xD. I will find another way to solve this problem mean while putting it here to see if there is any explanation for this. Thanks for collaborating as always 😄

anmonteiro13:06:27

@nxqd: pretty sure it’s unrelated to components having idents or not. You’ll only get links resolved if you’re using db->tree. Don’t expect magic to happen otherwise

peeja14:06:45

@jasonjckn: I'm pretty sure you can't literally transact inside an :action. Would it make sense to extract the behavior from the other mutation into a function and call it from both :actions?

peeja14:06:12

As I understand it, Om components aren't allowed to "steal" a child's query. That is, you query can't just be (query [this] (om/get-query ChildComponent)). I understand that that's true, but I don't entirely understand why. Can someone explain that (or point me to something)?

anmonteiro14:06:27

@peeja: the problem with stealing queries is that there’s no longer composition on that path in the tree

anmonteiro14:06:44

there will be no path from to root until that component

anmonteiro14:06:10

the path will end in the component that’s stealing the query

anmonteiro14:06:21

I hope I’m explaining myself well enough

peeja14:06:06

Ah, right, because you need a path of nodes in the query that are annotated with the components?

anmonteiro14:06:31

well that’s just an implementation detail

anmonteiro14:06:58

the reason is simply that you want to be able to compute the whole query for the application

anmonteiro14:06:17

if B is a child of A, and A steals B’s query, then B is just no longer part of the equation

anmonteiro14:06:15

(defui Root
  static om/IQuery
  (query [this]
    [{:a (om/get-query A)}]))

(defui A
  static om/IQuery
  (query [this]
    [(om/get-query B)])) ;; WRONG

(defui B
  static om/IQuery
  (query [this]
    [:foo :bar]))

anmonteiro14:06:29

path from Root to A is [:a] (hint: the join key)

anmonteiro14:06:43

what’s the path from A to B?

anmonteiro14:06:15

the answer is none, it can’t possibly know how to compose that path, and e.g. how to pass props to it

peeja14:06:25

Ah, I see.

peeja14:06:21

It feels just as wrong to me to just have Root use B's query directly, though. Root shouldn't know that what A needs is B's props.

peeja14:06:34

Is there a way around that?

anmonteiro14:06:04

I don’t understand the question, sorry

peeja14:06:51

The solution as I've seen it is:

(defui Root
  static om/IQuery
  (query [this]
    [{:a (om/get-query B)}]))

(defui A)

(defui B
  static om/IQuery
  (query [this]
    [:foo :bar]))

peeja14:06:29

But now Root gets a query from a component it doesn't render, which seems wrong. It has to know that A renders a B to know which component to get the query from.

peeja14:06:37

Is that not the correct solution?

anmonteiro15:06:06

depends on what the use case is

anmonteiro15:06:27

can also get-query Root -> A -> B

anmonteiro15:06:37

where A joins B’s query

anmonteiro15:06:46

but it needs to have a join key, such that there’s a path

peeja15:06:11

So I'd invent a join key for A -> B?

peeja15:06:35

Huh. I'm not sure how that would actually work in the parser, but I assume it would take a more sophisticated example to see what it takes. 🙂

peeja15:06:17

@anmonteiro: Thanks for the explanation!

ethangracer15:06:02

@anmonteiro: thanks, much appreciated!

ethangracer15:06:02

got it, awesome, back to fully functional over here

peeja15:06:21

In an app that has routing, the root query is going to change drastically from "page" to "page". Doesn't that throw off normalization?

peeja15:06:09

How can Om correctly normalize data that's not currently mounted on the page?

peeja15:06:04

Ah, does Om normalize data coming back from remotes based on the query that caused the read, rather than whatever the root query is at the time the callback is called?

anmonteiro15:06:29

@peeja: that’s right, you can pass the query as a 2nd arg to the callback in send

peeja17:06:20

I've got this demo app I'm playing with where I'm showing a list of items, and the details for a selected item from the list. If there's no item selected, I want to show no details. I'm storing the ident of the selected item as a query param. That works great, except: I don't know how to have a nothing-selected state. https://github.com/Peeja/om-next-starter/blob/list-noodling/src/om_starter/core.cljs#L84-L100

peeja17:06:04

Here, I'm defaulting the selected item to [:item/by-name "B"]. If :selected-item-ident were instead nil (which is what I'd like), the query would no longer be valid.

peeja17:06:52

Is there a good way around that? I could set-query! the entire query instead of the params, but that seems heavy-handed.

selfsame17:06:07

@peeja maybe set it to [:item/by-name :nf]

peeja17:06:30

:nf being a nonsense value?

peeja17:06:36

That might work

peeja17:06:49

Oh, actually, [:item/by-name nil] might work…

peeja17:06:10

It does! selected-item becomes {}, not nil, which I would have expected, but still, that'll do.

selfsame17:06:55

yeah db->tree joins won't be nil

peeja17:06:29

Got it. That makes sense.

jasonjckn18:06:35

would be nice for syntactic sugar reasons if \backtick* and \backtick_ were treated the same as '_ and '* in om.next