Clojurians Log v2

trying to implement the above, but not sure what's wrong

(defresolver response [{:keys [uri]}]   {::pco/output [::response]}   (p/let [response (http/get uri)]     {::response response}))  (def smart-map (psm/smart-map (pci/register response) {:uri "<https://pathom3.wsscode.com>"}))  (::response smart-map) =&gt; nil

@kevin842 you are using an async (returns a CompletableFuture) resolver with a sync runner (smart-maps) For now, as far i know, to async you need to use the "process" with env+query

@kevin842 you can't use async with smart maps, you need to use the async EQL process for this

ah thanks. don't see it mentioned in docs, will it be added someday?

nvm it is mentioned, but not too explicitly: To async, there is only the EQL interface

Hi, when I invoke my logout mutation and pass the values to it, inside it I see the namespace/request instead of the value, does anyone know why this happened?

(p.eql/process env
               [`(logout {::request request
                             ::url url
                             ::cookie-store new-c})])

its because you are using the backtick to expand, you have to use ~ before the values to get them there

(p.eql/process env
               [`(logout {::request ~request
                             ::url ~url
                             ::cookie-store ~new-c})])

thks

will pathom ever walk the same node twice? e.g. A->(B | C) C->target B->A' will pathom ever cycle back to A from A'? I have an alias resolver from A'->A but it seems it never walks back to A, to retry the A->C->target path again starting from A'

I believe the default behavior is that it won’t b/c the resolver’s response is cached for a specific input

that's a good point, but A' would have a different value than A (and I wouldn't want it to loop if they were equal), and I think the cache is keyed based on the resolver params?

tried setting ::pco/cache? false on everything, no diff

I had this mutation and when I invoke it, got this error Can't find a path for :async

(pco/defmutation logout [{::keys [request url cookie-store] :as logout-input}]
  (http/post url (assoc request :cookie-store cookie-store))
  logout-input)

(p.eql/process env
               [(logout {::request request
                             ::url url
                             ::cookie-store new-c})])

Ahhh, so in your example A' would go through the resolver A but it’s a different “id” from what the initial A resolver was called with

yeah, an alias-resolver creates that path from A' to A, i.e. A with the value of A'

pathom3 uses https://cljdoc.org/d/funcool/promesa/6.0.0/doc/user-guide. I’m not sure which http library you’re using but if it returns a promise you can do something like:

(:require [promesa.core :as p])

(pco/defmutation logout ...
  (p/let [response (http/post url)]
    ;; Use response as you'd like

nice, thanks for help me

if the lib uses core.async, then you can look into https://github.com/wilkerlucio/promesa-bridges

yes, Pathom may duplicate the same node in different points of execution, this may happen with OR cases

but no cycles

the planner never has cycles

got it. I just ended up explicitly specifying the connection. this is super cool.. I think I am actually going to try to replace my entire backend with pathom :p

the i/o parts at least

@matheusfrancisco001 I just noticed the way you are calling the mutation is wrong

you removed teh backtick thing

and the mutation needs to be as data

in the way you doing, you are invoking the mutation and returning is result as a query

the code we talked before was right, as:

(p.eql/process env
               [`(logout {::request ~request
                             ::url ~url
                             ::cookie-store ~new-c})])

☝️ this and what you are doing are not equivalent

Wow, thanks a lot!

it's worked.

debugging with pathom viz, I see that a node I expect to succeed has this attached to it:

:com.wsscode.pathom3.connect.runner/node-error  #object[Object [TaggedValue: unknown, #error {  :cause "Insufficient data"  :data {:required {:app.pathom.uri/response {}, :app.pathom.uri/response-url {}}, :available {}}

:com.wsscode.pathom3.connect.runner/node-resolver-input  {:app.pathom.uri/response ...   :app.pathom.uri/response-url ...}

not sure what the cause is.. the nodes go like response -> response-url -> OR -> (node with error | OR | another node)

the node with error is reachable through some queries but not others, even though they should follow the same initial path.. hm. seems I have to explicitly specify another attribute in the query, but I would expect pathom to be able to get to it regardless? should it be necessary to "hint" the planner like this?

yup, I keep doing that, a lot of Pathom Viz UI work is also supported by pathom inside 🙂

can you post what the failing query looks like and the relevant resolvers (pseudocode is fine)