Clojurians Log v2

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

@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"}))))

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

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

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

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

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

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

ok ok

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.

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

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.

Ok, nice use case indeed

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.

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

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

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

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

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

I wish Om queries had aliases like GraphQL 😞

@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]}]

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

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

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

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

you are on that one actually, hehe]

That must be what I'm thinking of 🙂

I take it that hasn't led anywhere yet?

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

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

In GraphQL, for instance:

{
  empireHero: hero(episode: EMPIRE) {
    name
  }
  jediHero: hero(episode: JEDI) {
    name
  }
}

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