Clojurians Log v2

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]}}}
  )

[{:authd/user [:user/email]}]
;; -> 
{:authd/user {:user/email "<mailto:foo@bar.com|foo@bar.com>"}}

@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...))

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

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!

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

awesome! pathom3 sounds great 🙂

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

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

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

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

thanks for the suggestion!

I’m enjoying the second Pathom episode! https://soundcloud.com/user-959992602/s4-e16-pathom-with-wilker-lucio-part-2