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’t like it

hkjels06:06:14

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

iwankaramazow06:06:13

@hkjels: looks fine to me 🙂

iwankaramazow06:06:43

ah a second, I see

hkjels06:06:48

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

hkjels06:06:37

except with process-roots that is, but it seems that’s 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’s not documented, but it’s 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’d prefer to actually pass the parents key into the parser

hkjels07:06:54

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

iwankaramazow07:06:49

Do you have an example?

hkjels07:06:44

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

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’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

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

mitchelkuijpers10:06:05

Absolutely @anmonteiro

dobladez12:06:10

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

anmonteiro12:06:54

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

anmonteiro12:06:57

what’s 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’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?

hkjels13:06:07

as far as I can see, I’m 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’t 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’s 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’m stuck with the same undesired effect of having to name my route from my child-reader

hkjels13:06:16

I’m 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 (…) ??