Fork me on GitHub

Can nested entities “see” the outer context while in a pathom process? I thought I saw this in use at some point, but it’s not working now.

  {:root/some-data :some-data
   :nest {}}
   {:nest [:root/some-data]}])

=> {:root/some-data :some-data, :nest {}}


no, they cant, if you want that the parent must forward that data down


How could I make the data forwarded?


copy it over at the higher resolver


in the resolver of :root/some-data, get the input and copy into the items, makes sense?

Drew Verlee15:08:45

;; I'm not sure how to extend this resolver to use a pathom parameter

(pco/defresolver foo
  [{id :a/id}]
  {::pco/output [:a/b :a/c]}
  (get {1 {:a/b 1 :a/c 2}} id))

;; first, it seems necessary to extend the number of arguments it takes to get the env variable

(pco/defresolver foo1
  [env {id :a/id}]
  {::pco/output [:a/b :a/c]}
  (get {1 {:a/b 1 :a/c 2}} id))

;; as an aside its odd that even though the first argument to p.eql/process is the id, it now comes as the second argument

(p.eql/process (pci/register foo1)
               {:a/id 1})

;; The real issue how ever is how to pass a pathom parameter now

(p.eql/process (pci/register foo1)
               {:a/id 1}
               ;; i'm assuming this should be of the grammar here 

;; But it's not clear how or what. First lets use our param instead of the input

(pco/defresolver foo2
  [env {id :a/id}]
  {::pco/output [:a/b :a/c]}
  (get {1 {:a/b 1 :a/c 2}} (-> env pco/params :param/id)))

(p.eql/process (pci/register foo2)
               {:a/id 1}
               );; => nil

(p.eql/process (pci/register foo2)
               {:a/id 1} ;; ignoring this on purpose
               ;; if we look at this example 
               ;; (p.eql/process env ['(::todos {::todo-done? false})])
               ;; then we should pass a vector, but the second argument is a list with one key. What does that mean?
               ;; in our example here, the output isn't one map but two, so where does the "with param"/param go?
               ;; we trying something random
               ['(:a/b {:param/id 1})]
               ;; it doesn't work
               );; => nil


hello, can you tell a bit more concretely what you looking for? I'm not sure if I get what you trying to do yet


about the signature, think this way, resolvers *always* take 2 parameters, the thing is that the defresolver macro will fill in if env is missing, but if you need env (and you do need it for params), then you add it before


I think the following example may help with it:


(pco/defresolver param-item [env {:keys [id]}]
  {::pco/output [:a :b]}
  {:a (pco/params env)
   :b (pco/params env)})

    (pci/register param-item)
    {:id 1}
    ['(:a {:foo "bar"})



=> {:a {:foo "bar"}, :b {:foo "bar"}}


when doing params with resolvers that have multiple outputs, remember they will share the params


would love some feedback on how we can improve the docs for it

Drew Verlee17:08:07

@U066U8JQJ i'm mostly trying to learn pathom, so this is very helpful. Interestingly, the code i linked actually now returns the correct result. Which makes me believe my repl had ended up in some corrupted state. Such is life? I'm hesitant to recommend changes to docs without a better understanding. but here are a few things that caused some confusion. It's unclear what arguments defresolver takes. Ideally i could look at the function signature and at least have idea. I'm not sure why are we passing what seems to be a global param attached to any particular "attribute" (e.g (':b {:foo "bar"}) , please correct if me if this is the wrong term). In this example it's taking the first instance of the param and ignoring the second. (p.eql/process (pci/register param-item) {:id 1} ['(:b {:foo "car"}) '(:a {:foo "bar"}) ]);; => {:b {:foo "car"}, :a {:foo "car"}} Why not have it as a completely separate argument? I suspect there is a good reason it just hasn't clicked for me yet. Again, my goal was just to learn. My primary confusion was because as the oringal example shows, i was getting nil as where the same code now evals to {:a/b 1} the expected output. Ty for taking the time to answer my questions.


params are per resolver, it makes more sense if understand how the planning works (, it goes scanning the query figuring out what resolvers get called, when it sees an attribute it adds the params to that resolver call (that's why it comes from the env, the pco/params helper will find the node representing that resolver execution and pull the params definition from there)


that said, params are mostly used in resolvers with a single list in the output, to do things like pagination or some basic filtering, if the param is intended for something else, you should consider making it an input instead, inputs are a preferable way in general to give more data then params is (since they can participate in the resolution process, meaning their implementation remains open and can evolve)