Fork me on GitHub
#pathom
<
2020-03-04
>
tvaughan13:03:56

Let's say I have a query like [{[:person/id ""][:person/name]}] How do I get access to [:person/name] in my resolver? I have a resolver like:

(pc/defresolver person-resolver
  [env {:keys [person/id] :as params}]
  {::pc/input #{:person/id}
   ::pc/output [:person/name :person/email]}
...)
and I don't see where I could grab this out of env

wilkerlucio13:03:03

@tvaughan in the resolver you described, you have to provide the :person/name, if you want to use :person/name as input for something, you can create another resolver that depends on it, makes sense?

tvaughan13:03:17

> makes sense? No, sorry. I mean a client can submit a query like: [[:person/id 42]] which means "return everything" or [{[:person/id 42][:person/name]}] which means "return only :person/name. Right now the resolver returns everything and Pathom returns only what has been requested. However, in my resolver I don't want to fetch everything, I only want to fetch what the client requested. Which means my resolver needs to know what the client sent beyond just the person id. How?

yenda13:03:56

in env you want to get ::p/keys [parent-query]

yenda13:03:47

for instance I do

(reduce (fn [acc field]
                          (conj acc (if (keyword? field)
                                      field
                                      (first (first field)))))
                        #{}
                        parent-query)
to then only select those fields in my sql query

yenda13:03:50

if the query is a mutation then I do (get-in env [ast :query])

souenzzo14:03:40

Return basead on parent-query isn't always a good solution It may kill the "connect superpowers"

(let [register [(pc/resolver
                  `user-by-id
                  {::pc/input  #{:user/id}
                   ::pc/output [:user/email
                                :user/name]}
                  (fn [{::p/keys [parent-query]} {:user/keys [id]}]
                    (-> {:user/email (str id "@example.com")
                         :user/name  (str id)}
                        (p/map-select parent-query))))
                (pc/resolver
                  `slug-by-email
                  {::pc/input  #{:user/email}
                   ::pc/output [:user/slug]}
                  (fn [env {:user/keys [email]}]
                    {:user/slug (first (string/split email #"@"))}))]
      parser (p/parser {::p/plugins [(pc/connect-plugin {::pc/register register})]})
      env {::p/reader              [p/map-reader
                                    pc/reader2
                                    pc/open-ident-reader]}]
  (parser env `[{[:user/id 42] [:user/name
                                :user/slug
                                :user/id
                                #_:user/email]}]))

tvaughan15:03:56

Thanks @U2J4FRT2T This is what I have now:

(pc/defresolver person-resolver
  [{:keys [::p/parent-query] :as env} {:keys [person/id] :as params}]
  {::pc/input #{:person/id}
   ::pc/output [:person/name :person/email]}
  (datomic/q-by-ident (datomic/conn->db conn) [:person/email id] parent-query))

souenzzo15:03:14

I already used it in a project and I moved back to (d/pull db (-> env ::pc/resolver-data ::pc/output) ei ) after some connect issues

yenda16:03:36

I dont understand could you elaborate what it kills?

yenda16:03:05

What is the alternative?

souenzzo16:03:13

always return "everything" in resolver

yenda19:03:10

for me that is not an option the resolver is doing a composed sql query with different aggregates to limit roundtrips to the db server

tvaughan14:03:43

Oh, it seems as though Pathom doesn't support a query like my first example: [[:person/id 42]], right? Instead Pathom requires queries like my second example: [{[:person/id 42][:person/name :person/preferred-pronouns]}] , correct? A query like [[:person/id 42]] doesn't trigger the person/id resolver

wilkerlucio14:03:52

@tvaughan exactly, pathom only loads things that the user requires, you may have dozens of resolvers that can get something from :person/id, Pathom optimizes to fulfill the client demand (which should be precise, the EQL request must be explicit about what it wants, by design)

👍 4
mss17:03:50

is there an easy way when getting a parallel read timeout w/ the async parser to trace down what resolver is timing out?

kszabo18:03:00

not by default AFAIK