This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2016-06-14
Channels
- # admin-announcements (2)
- # beginners (32)
- # boot (217)
- # cider (20)
- # cljsjs (25)
- # cljsrn (9)
- # clojure (87)
- # clojure-android (7)
- # clojure-austin (4)
- # clojure-belgium (10)
- # clojure-canada (13)
- # clojure-dev (28)
- # clojure-dusseldorf (2)
- # clojure-greece (119)
- # clojure-nl (1)
- # clojure-russia (22)
- # clojure-spain (3)
- # clojure-spec (81)
- # clojure-uk (54)
- # clojurescript (32)
- # community-development (2)
- # core-async (19)
- # cursive (18)
- # datascript (5)
- # datomic (1)
- # dirac (22)
- # emacs (22)
- # hoplon (198)
- # incanter (1)
- # instaparse (4)
- # jobs (3)
- # keechma (15)
- # ldnclj (2)
- # lein-figwheel (14)
- # mount (8)
- # om (78)
- # om-next (4)
- # onyx (37)
- # other-languages (1)
- # pedestal (6)
- # re-frame (22)
- # reagent (25)
- # ring-swagger (17)
- # robots (1)
- # slack-help (1)
- # spacemacs (7)
- # specter (50)
- # spirituality-ethics (3)
- # uncomplicate (5)
- # untangled (1)
- # yada (17)
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})))
This works, but I don’t like itexcept 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
Power users like Tony.Kay aren't happy with the limitations of process-roots
, his framework takes another approach
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 \"[email protected]\"]
with wrap-transi-params I get :transit-params nil
could it be that I'm just sending a nil from om?
@iwankaramazow: hopefullly anmonteiro will answer us today regarding the yesterday's discover 😄
Would this help? https://github.com/anmonteiro/compassus/blob/master/src/main/compassus/core.cljs#L125
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
But I think the problem also is mutations, there you also need to know that key
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"})])
but the properties only: {:claims/current {}}
no, I just gave it explicit value for debugging, otherwise I would have it in IQueryParams and :claim-id ?claim-id in the query.
(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.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}))
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 🙂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))))}
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
@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)})))
'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)})))
this will result in a query [{:active-props: [{:projects [:other-query-stuff]}]}]
rewritten to [{:projects [:other-query-stuff]}]
(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))))
the response will go from [{:projects [:other-query-stuff]}]
back to [{:active-props: [{:projects [:other-query-stuff]}]}]
on rewrite