Fork me on GitHub
#om
<
2016-06-14
>
hkjels05:06:09

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

hkjels06:06:37

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})))
This works, but I don鈥檛 like it

hkjels06:06:14

The part with the route is the one I don鈥檛 like

iwankaramazow06:06:13

@hkjels: looks fine to me 馃檪

iwankaramazow06:06:43

ah a second, I see

hkjels06:06:48

So there鈥檚 no way to do this without this reader having knowledge of it鈥檚 parent?

hkjels06:06:37

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

iwankaramazow06:06:01

(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)})))

iwankaramazow06:06:09

;; 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))))

iwankaramazow07:06:13

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

hkjels07:06:29

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

hkjels07:06:51

OK, thank you

iwankaramazow07:06:56

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

iwankaramazow07:06:44

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

hkjels07:06:27

I鈥檇 prefer to actually pass the parents key into the parser

hkjels07:06:54

That way, the child would not have to worry if it鈥檚 the root

iwankaramazow07:06:49

Do you have an example?

hkjels07:06:44

Not really, haven鈥檛 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

hlolli07:06:04

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

jimmy09:06:42

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

jimmy09:06:11

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

anmonteiro09:06:00

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

anmonteiro09:06:48

Oh this is one level deeper

anmonteiro09:06:22

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

anmonteiro09:06:39

I just noted it as a TODO

mitchelkuijpers09:06:39

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

mitchelkuijpers09:06:03

Something like a :path parameter in env

mitchelkuijpers09:06:45

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

dobladez12:06:10

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

anmonteiro12:06:54

@dobladez: no, it鈥檚 not meant for that

anmonteiro12:06:57

what鈥檚 the use case?

dobladez12:06:39

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

dobladez12:06:54

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

hlolli12:06:31

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"})])
but the properties only: {:claims/current {}}

iwankaramazow12:06:43

the :claim-id is stored in IQueryParams?

hlolli12:06:32

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

iwankaramazow12:06:13

can you show me some of the relevant parser code?

hlolli12:06:14

(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}))
:ess-om is listed in remote in the reconciler, and the correct data I have in my @app-state. So the remote fetch succeeds.

iwankaramazow12:06:30

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

hlolli12:06:30

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?

iwankaramazow12:06:05

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

hlolli12:06:49

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

iwankaramazow12:06:30

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

iwankaramazow12:06:20

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

hlolli12:06:27

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}))
I only get empty map. But the fact that I get this response {:claims/current {:claim-id \"1144526731160\", :transmissions [{:icn \"30000002041450\", :frequency :adjustment, :status :adjusted, ...etc... is still a puzzle. But Im going to research this deeper then, 99% of the bugs Ive been getting in om.next tend to be foolishness so far 馃檪

hlolli12:06:05

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

iwankaramazow12:06:39

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

hlolli12:06:32

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

iwankaramazow13:06:13

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

hlolli13:06:44

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!

iwankaramazow13:06:07

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

hlolli13:06:07

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

hkjels13:06:49

@iwankaramazow: I鈥檓 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?

hkjels13:06:07

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

iwankaramazow13:06:52

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)})))
'child' of the join
(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)})))

iwankaramazow13:06:52

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

hkjels13:06:14

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

hkjels13:06:59

Ehmn. It should then be merged back in as {:projects 鈥 shouldn鈥檛 it?

iwankaramazow13:06:46

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

iwankaramazow13:06:51

(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))))

iwankaramazow13:06:09

before the merge happens, you invoke rewrite

hkjels13:06:57

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

iwankaramazow13:06:08

what do you mean?

iwankaramazow13:06:38

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

hkjels13:06:46

it鈥檚 merged back in below {:active-props} in your case

iwankaramazow13:06:08

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

hkjels13:06:47

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

hkjels13:06:16

I鈥檓 probably just over-complicating things

hkjels13:06:38

Anyways, I have to run. See you later

urbanslug14:06:27

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

hlolli15:06:32

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

urbanslug20:06:00

:value (鈥) ??