Fork me on GitHub
#om
<
2017-03-10
>
ag04:03:28

has anyone ever used ref? can someone show me a piece of snippet where the component ref is being set and then used?

anmonteiro04:03:49

@ag

(defui Child
  Object
  (render [this]
    (dom/div nil "hello from child")))

(defui Parent
  Object
  (render [this]
    (dom/div nil
      ((om/factory Child) {:ref "child-component"}))))

ag04:03:24

oh, ok. how about attaching it from inside the components itself and then accessing within it too?

ag04:03:25

I dunno if I’m trying to use the right tool though. So basically I need to access one of the dom elements from within a component. e.g. you have two input fields and then based on what’s typed in one you have to focus on the second field

ag05:03:09

@anmonteiro oh I think I got it, something like this:

(render [this] (html [:input {:ref #(aset this (str “yo-input-yo" %)}]))

baptiste-from-paris10:03:16

Has anyone ever use (om/shared this) and in which typical use case ?

danielstockton10:03:43

I just noticed :shared-fn and looks like it might be useful for something like 'current logged in user'.

danielstockton10:03:51

Pretty much all my components have something like translation to do and I need the current user's locale. It looks like it might be useful for that, until now i've been passing user down by hand.

danielstockton10:03:30

In my case the root props are (:compassus.core/route :compassus.core/route-data :compassus.core/mixin-data) which doesn't seem so useful.

danielstockton10:03:51

Actually, I can get current user with :shared-fn (fn [props] (println (-> props :compassus.core/mixin-data :user))). Looks like it will do the job nicely.

baptiste-from-paris10:03:30

Ok, nice use case indeed

danielstockton10:03:54

Use case number 2 - it seems a nice place to have easy access to history (pushy, lets me set routes). Until now, i assoc'd it onto the reconciler.

petterik15:03:12

I use shared for history, like daniel said. I've also put a local-storage record in there instead of using js/localStorage directly, so I can fake it and test it in clj

peeja20:03:34

What do you do when two subcomponents need to read from the same key?

peeja20:03:00

(I feel like I've asked this before but haven't found a satisfactory answer yet.)

peeja20:03:12

I guess the best thing I've seen thrown around so far involves "placeholder" keys that the parser ignores

peeja20:03:27

but that give the two components different places to live in the query tree

peeja20:03:51

I wish Om queries had aliases like GraphQL 😞

wilkerlucio21:03:00

@peeja a lot of people lead to something like "placeholder nodes", for example, you can make your server understand any query that starts with ph to be a "placeholder node", where it goes down one level on the data tree, but logically it stays on the same position, enabling you to query like: [{:ph/view-a [:some-data :more-data]} {:ph/view-b [:other-data :more-data]}]

wilkerlucio21:03:22

the advantage is that you keep Om.next index happy about it, since each result will be correctly marked with the component meta data

peeja21:03:40

Oh, you'd put that on the server? I'd assume the local parser would want to clean all of that up

wilkerlucio21:03:19

yeah, I could not figure another way to handle this, this one looks weird at first, but works nicely once you have it setup

wilkerlucio21:03:06

@peeja there were a discussion about this before, here: https://github.com/omcljs/om/issues/823

wilkerlucio21:03:14

you are on that one actually, hehe]

peeja21:03:22

That must be what I'm thinking of 🙂

peeja21:03:34

I take it that hasn't led anywhere yet?

wilkerlucio21:03:56

nop, as far as I know, nobody came up with a different solution yet

peeja21:03:26

I suppose this also means there's no good way in Om to ask for two different things by the same key, but with different params

peeja21:03:58

In GraphQL, for instance:

{
  empireHero: hero(episode: EMPIRE) {
    name
  }
  jediHero: hero(episode: JEDI) {
    name
  }
}
http://graphql.org/learn/queries/#aliases

peeja21:03:28

That is, no way without implementing placeholder keys. But then you really would have to do it on the server as well.