Fork me on GitHub
#pathom
<
2020-11-11
>
dehli12:11:07

Hi, I have a question about resolvers and input. The following code doesn’t work, but I’m wondering if there’s a way to accomplish the same thing (or maybe I’m doing something wrong). Also thanks for all the advice so far! I’m really enjoying pathom.

(pc/defresolver authd-resolver
  [_ _]
  ;; This is a globally accessible resolver
  {:authd/user {:user/id "foo"})

(pc/defresolver user-resolver
  [_ {:user/keys [id]}]
  {::pc/output [:user/email]}
  ;; Retrieve the user from db (currently just a stub)
  {:user/email (str id "@bar.com")})

(pc/defresolver custom-resolver
  [_ params]
  ;; this part doesn't work for me and neither does #{:authd/user :user/email} 
  {::pc/input #{{:authd/user [:user/email]}}}
  )
Note: if I simply query for data like below I do get the expected response:
[{:authd/user [:user/email]}]
;; -> 
{:authd/user {:user/email ""}}

souenzzo13:11:15

@dehli ::pc/input is a (s/coll-of keyword? :kind set?), not a EQL pattern I already requested this feature some time ago. But it's a pretty hard problem. You can use

(pc/defresolver custom-resolver
  [{:keys [parser] :as env} _]
  {::pc/output [...]}
  (let [email (->> [{:authed/user [:user/email]}]
                   (parser env)
                   :authed/user
                   :user/email)]
    ...email...))

souenzzo13:11:08

In my current app i created :app.authed-user/email, :app.authed-user/id so i can easily access it.

dehli13:11:08

Thanks @souenzzo! I will search for that feature to give it a 👍 but I can imagine it being difficult. I’ll go down the route you suggested of creating a separate resolver for those specific authd fields I need often thought. Thanks again for the help!

souenzzo13:11:54

Not sure if there is a issue for it But in pathom3** the :input is already specified as EQL pattern, although AFIK it still just use the "top level" keys. not released // in design

dehli13:11:51

awesome! pathom3 sounds great 🙂

wilkerlucio14:11:13

yes, I plan to support that in pathom3 in the future, I call “nested inputs”. this is specially needed when integrating with dynamic resolvers, like graphql

🎉 2
wilkerlucio14:11:55

and like @souenzzo said, currently you can kind achive that by doing a recursive call to the parser

wilkerlucio14:11:58

on difference though, I suggest having an input (without the nesting) in the resolver config anyway, otherwise you risk pathom trying to trigger that resolver even when there is no path available for the input

dehli15:11:38

thanks for the suggestion!

wilkerlucio14:11:58

Pathom 3 documentation site is out! That and a few more updates at https://blog.wsscode.com/pathom-updates-03/

🔥 11
🎉 4
parrot 3
😍 1