Fork me on GitHub
#om
<
2016-09-28
>
wilkerlucio11:09:47

@peeja I had ran into a similar issue regarding the aliasing, my solution was to create what I call "placeholder nodes", a placeholder node will move the join one level down, but still remain at same logical access level, in your case for example, the solution would be to write the query as [{:ph/user-for-subcomponent [{:app/current-user (om/get-query User)}]} {:app/current-user [:user/name]}]

wilkerlucio11:09:41

in my parser, I treat any keyword with a ph namespace as a placeholder node, it calls the parser again sending the children

peeja14:09:00

@wilkerlucio Yeah, I've been thinking about doing something like that.

wilkerlucio15:09:03

@peeja cool, please let me know if figure another way of doing it

peeja15:09:39

@anmonteiro FWIW, I'm configuring our parser to skip over the root keys (the route key) in its queries and read route component queries as if they were at the root. In fact, I'm not sure why it's terribly useful to have the root key of the queries my parser sees be the route key. If that turns out to be a common pattern for Compassus users, maybe it would be worth having an option that would treat route component queries as root queries built into Compassus?

peeja15:09:00

It could be an alternate parser builder

peeja15:09:16

Or maybe I'm missing out on something important by skipping over these keys 馃檪

anmonteiro15:09:45

@peeja let me see if I understand what you鈥檙e saying. You mean that if you have this (sub)query:

{:index [:page/title :page/content]
 :about [:page/title :page/content :other/key]}
you鈥檙e making the parser ignore :index and :about and dispatch on the specific keys that make the underlying route query?

peeja15:09:11

That's right

peeja15:09:31

I don't want my parser to know about each route, in other words

anmonteiro15:09:36

definitely open to think about a knob to handle that in Compassus

anmonteiro15:09:46

feel free to open an issue

peeja15:09:56

I want each route to have access to the same keys, which (roughly) match the root keys of the app state

anmonteiro15:09:23

@peeja also I think at this point you already have some knowledge on the inner workings of Compassus? 馃檪

anmonteiro15:09:39

if that鈥檚 the case, feel free to suggest alternatives

peeja15:09:00

Happy to PR it if it's something you're open to

peeja15:09:41

Yeah, that sounds right

anmonteiro15:09:46

instead of returning [{route subq}], just return subq

anmonteiro15:09:11

@peeja it would be great if we could just infer this based on the type of parser that the user is feeding us

anmonteiro15:09:25

PRs more than welcome as long as you include tests!

anmonteiro15:09:54

@peeja 鈥渢ype鈥 is probably the wrong phrasing

anmonteiro15:09:41

I鈥檓 thinking about somehow inferring that your app feeds a parser like what you described above so we should just dispatch on the subq

anmonteiro15:09:07

but that鈥檚 probably not a very good idea as it would not be a very self-documenting behavior

anmonteiro15:09:32

also not sure if there鈥檚 some sound heuristic to infer that, given that parsers can either be simple functions, multimethods, core.match matchers etc.

peeja15:09:06

Yeah, I think it needs to be told

peeja15:09:35

There's also nothing stopping you from using a key as both a route key and a key in the route's subquery

peeja15:09:41

(I mean, nothing but good taste)

peeja15:09:55

It's unfortunate that there's no way to call a parser and get its mutation description (`:value` and :action) without actually executing the action

hlolli16:09:49

that would be acessable from the defmulti if its accessable at all? Dont know much about metadata on multimethods.

steveb8n17:09:32

@anmonteiro that was a really fast response. I鈥檒l play with that idea https://anmonteiro.com/2016/01/exploration-patterns-om-next-part-2

anmonteiro17:09:54

yeah, I got the email

steveb8n17:09:48

and BTW, thanks for the server side rendering work. it makes playing around and testing so much easier

levitanong17:09:32

by the way, @anmonteiro any chance you could follow up with david on the contributor agreement? 馃槢

anmonteiro18:09:12

@levitanong I don鈥檛 have special access to him or anything, he鈥檚 normally responsive when you ping him here for example

levitanong18:09:27

Oh, okay then!

levitanong18:09:16

@dnolen Hello! Sorry to bother you, but I sent you an email a few days ago about the contributor agreement. Have you received it?

levitanong18:09:05

@dnolen Hurrah! Thanks 馃槃

levitanong19:09:21

Is it expected behavior for a Component defined by defui to have a different value when referenced in a static method vs non-static method?

(defui Component
  static SomeProtocol
  (protocol-imp [this] (println Component)) ;; returns some expected representation of Component, complete with meta
  Object
  (render [this] (println Component))) ;; returns some fn

Joe R. Smith20:09:21

hmm, if a transaction re-reads an some attribute for an entity and the server doesn鈥檛 respond with the entity鈥檚 ident attribute, the data won鈥檛 get properly normalized. Does this mean the server needs to both know what attribute is being used as part of the entity鈥檚 ident and that it should always be included in the response?