Am I suppose to use the undocumented process-roots with compassus to ignore the root-components key?

or is there another cleaner way?

(defmethod read :list/lifelines
  [{:keys [state ast]} k _]
  (let [st    @state
        route (:compassus.core/route st)
        value (get-in st [route k])]
    (if-not (empty? value)
      {:value value}
      {:remote ast})))

The part with the route is the one I don’t like

@hkjels: looks fine to me 🙂

ah a second, I see

So there’s no way to do this without this reader having knowledge of it’s parent?

except with process-roots that is, but it seems that’s only suppose to be used internally by om.next

(defmethod read :list/lifelines
  [{:keys [state ast]} k _]
  (let [st    @state
        route (:compassus.core/route st)
        value (get-in st [route k])]
    (if-not (empty? value)
      {:value value}
      {:remote (assoc ast :query-root true)})))

;; fake a send to the fake backend
(defn send [{:keys [remote]} merge]
  (let [{:keys [query rewrite]} (om/process-roots remote)
        response (backend-parser {:database fake-database} query)]
    (println "incoming query" query)
    (println "response" response)
    (merge (rewrite response))))

process-roots is used in the send function, where it strips of the root of the query in favor of the one you marked with :query-root true

yeah. I just thought it was not idiomatic om.next, since it’s not documented, but it’s perhaps not documented; yet

OK, thank you

It's not documented yet. Personally I use it all the time

Power users like Tony.Kay aren't happy with the limitations of process-roots, his framework takes another approach

I’d prefer to actually pass the parents key into the parser

That way, the child would not have to worry if it’s the root

Do you have an example?

Not really, haven’t given it too much thought. But basically the parent could say what path the child should use, so you would end up with a smaller set from the state

@nxqd: I added tempids to the example: https://gist.github.com/IwanKaramazow/81c9df568e400d50bbf82aad04f71b40

A short transit question, how do I parse this from :body #object[java.io.ByteArrayInputStream 0x18133693 \"java.io.ByteArrayInputStream@18133693\"] with wrap-transi-params I get :transit-params nil could it be that I'm just sending a nil from om?

@iwankaramazow: awesome, thanks 😄 ready to roll on om today 😄

@iwankaramazow: hopefullly anmonteiro will answer us today regarding the yesterday's discover 😄

@hkjels: wouldnt route in your example be the same as k?

Oh this is one level deeper

It's not clear to me what you want to achieve

Would this help? https://github.com/anmonteiro/compassus/blob/master/src/main/compassus/core.cljs#L125

I just noted it as a TODO

Ooh that’s a good idea @anmonteiro I was also thinking of a solution like that for my own queries that I would like to nest arbitrarily

Something like a :path parameter in env

But I think the problem also is mutations, there you also need to know that key

Absolutely @anmonteiro

In compassus: May I have a query in my wrapper component?

@dobladez: no, it’s not meant for that

what’s the use case?

I'm tryig to plug compassus in my (prototype) app, and felt like making my root component the wrapper was natural

my root component has "common presentation logic for all the routes", but it needs to query for state

With parameterized query read with remote. Is there any trick to render the read? I have my data in the app-state atom, and om/props and the app-state are not in sync. My query is this

(query [_]
   '[(:claims/current {:claim-id "1144526731160"})])

the :claim-id is stored in IQueryParams?

no, I just gave it explicit value for debugging, otherwise I would have it in IQueryParams and :claim-id ?claim-id in the query.

can you show me some of the relevant parser code?

(defmethod read :claims/current
  [{:keys [state query]} k {:keys [claim-id]}]
  (let [st @state]
    {:value (om/db->tree query [:claims/by-id claim-id] @state) 
     :ess-om true}))

If you console.log (om/db->tree query [:claims/by-id claim-id] @state) , do you get the right value?

I'm note sure where I should console.log this, as it needs transit? In the backend code, I print the transit response, which looks exacly the same as if I dereference app-state in the front-end. But Im not sure how I could console.log this query?

If I understand correctly, a read of :claims/current doesn't render correctly on the frontend?

yes, thats the problem, all other reads render correctly. First time just doing parameterized :remote, so... bit confused.

That shouldn't change much. 1) if you log the incoming query on the backend, is it the right one? 2) if the response arrives back at the client, is it the right one? 3) check if the output of (om/db->tree query [:claims/by-id claim-id] @state) in your parser is correct with println

It might also be worth checking {:keys [claim-id]} if claim-id is the right value

ok, this could be a backend problem, as I didn't write the datomic pull. Because if I do

(defmethod read :claims/current
  [{:keys [state query]} k {:keys [claim-id]}]
  (let [st @state]
    {:value (do (println (om/db->tree query [:claims/by-id claim-id] @state))
                (om/db->tree query [:claims/by-id claim-id] @state)) 
     :ess-om true}))

anyway, may add that query from {:keys [state query]} returns nil.

You might need to update the ast in the client parser if you want the correct value

ok, this could be it. I just posted the client parser. But could it be the problem, that the response from the backend (POST) needs to be in the form of AST?

{:status 200 :body (into {} (map (fn [[k v]] [k (pull-up-ids k v)])
                                          (parser/parse {} (:transit-params request))))}

the query on the client dictates the format you'll need to return

yes, I think the backend is correct. You said adjusting the ast in the client, so I'm going to look more into that. Thank you for taking the time!

If you don't find the cause, give me a link to a github project. I'll make a PR

ok, I will. I give myself 24 hours for a bug before I cry for help. 🙂

😄

@iwankaramazow: I’m testing process-roots, but the query does not seem to be rewritten. Does the parent read-fn have to do anything in-particular besides setting :remote true?

as far as I can see, I’m doing exactly like you sketched out in those snippets earlier

example parent:

(defmethod read :active-props
  [{:keys [parser query ast target] :as env} key _]
  (let [remote (parser env query target)]
    (if (and target (not-empty remote))
      {:remote (update-in ast [:query] (fn [query] remote))}
      {:value (parser env query)})))

(defmethod read :projects
  [{:keys [state ast query query-root]} k _]
  (let [st @state]
    (if-let [x (get-in st [:active-props k])]
      {:value (om/db->tree query x st)}
      {:remote (assoc ast :query-root true)})))

this will result in a query [{:active-props: [{:projects [:other-query-stuff]}]}] rewritten to [{:projects [:other-query-stuff]}]

Dough! It worked, only not how I expected, hehe. Sorry

😄

Ehmn. It should then be merged back in as {:projects …} shouldn’t it?

That's why process-roots gives you a rewrite function

(defn send [{:keys [remote]} merge]
  (let [{:keys [query rewrite]} (om/process-roots remote)
        response (backend-parser {:database fake-database} query)]
    (println "incoming query" query)
    (println "response" response)
    (merge (rewrite response))))

before the merge happens, you invoke rewrite

weird. It somehow ends up at that root-key anyways ;(

what do you mean?

the response will go from [{:projects [:other-query-stuff]}] back to [{:active-props: [{:projects [:other-query-stuff]}]}] on rewrite

it’s merged back in below {:active-props} in your case

yeah

this is desired, because my ui queries start from :active-props

OK, so I’m stuck with the same undesired effect of having to name my route from my child-reader

I’m probably just over-complicating things

Anyways, I have to run. See you later

Does anyone have a good way of taking a password from a password field in Om Now?

(.-value (gdom/getElement "div-id")) ? (then hash it with buddy-hashers?)

:value (…) ??