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

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

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

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

@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?

It could be an alternate parser builder

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

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

{:index [:page/title :page/content]
 :about [:page/title :page/content :other/key]}

That's right

gotcha

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

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

feel free to open an issue

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

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

if that’s the case, feel free to suggest alternatives

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

I think this is actually something we could solve easily in: https://github.com/compassus/compassus/blob/master/src/main/compassus/core.cljc#L131

Yeah, that sounds right

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

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

Type?

PRs more than welcome as long as you include tests!

@peeja “type” is probably the wrong phrasing

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

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

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

Yeah, I think it needs to be told

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

(I mean, nothing but good taste)

true

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

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

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

yeah, I got the email

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

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

@levitanong I don’t have special access to him or anything, he’s normally responsive when you ping him here for example

Oh, okay then!

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

@levitanong sent

@dnolen Hurrah! Thanks 😄

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

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