Fork me on GitHub

@wilkerlucio not sure if i’m misunderstanding how resolvers work, but I created an ident resolver to get additional information over the network about a specific entity. Additional information was to be passed in params, so in my call to df/load, i passed a params map expecting that in my resolver I could get it from the AST. However, when I looked at the AST inside the resolver, it was a :prop AST for only one of several props i declared in my output. What i expected was an AST that was of type :root, and had a :params key in there. Am I misunderstanding the usage of this, or is this a bug?

Björn Ebbinghaus10:01:22

Can you provide the query?


(defsc FooWithAdditionalInformation
  [this props]
  {:ident [:foo/by-id :foo/id]
   :query [:foo/id :foo/bar :foo/baz]})

(df/load this [:foo/by-id 0] FooWithAdditionalInformation
  {:params {:other-data other-data}})
Inside the resolver the ast is:
{:type :prop, :dispatch-key :foo/baz, :key :foo/baz}]
The root query is:
[([:foo/by-id 0] {:other-data other-data})]


@wilkerlucio that’s not exactly the case. I don’t even get the params in my resolver. Also, the ast I get is for a property of one of the outputs, not the join around all of them. So it seems like the wrong ast is being passed to the resolver.


@U0BR5D7A6 You can use a plugin to make sure every resolver gets the parameters you pass. It is part of Fulcro RAD but I'll copy it in here. You access them as query-params .


(def query-params-to-env-plugin
  "Adds top-level load params to env, so nested parsing layers can see them."
   (fn [parser]
     (fn [env tx]
       (let [children (-> tx eql/query->ast :children)
             query-params (reduce
                            (fn [qps {:keys [type params] :as x}]
                              (cond-> qps
                                      (and (not= :call type) (seq params)) (merge params)))
             env (assoc env :query-params (dissoc query-params :pathom/context))]
         (parser env tx))))})


@U0D5RN0S1 thanks! your tip worked like a charm.

simple_smile 4

reading documentation on resolvers, wondering if I should be wary of automatic data dependency resolution  i.e. in docs, this snippet [{::latest-product [:product/title :product/brand-id]}] ::latest-product doesn’t return :product/brand-id directly, but because it returns `:product/id` pathom can use product-brand resolver to get :product/brand and then brand-id-from-name to get :product/brand-id in contrast with graphql resolvers, you declare how a property can be retrieved explicitly. Which is less powerful, but I feel like things can break easily if you're not exact about what depends on what. wondering if this is an issue ppl experience with pathom, or if I just need to change my mental model to accommodate the automatic data dependency resolution

Chris O’Donnell16:01:09

I think that transitive dependency resolution is what makes pathom really shine. It lets you decouple the fetching of different attributes of an entity. I have not used pathom in production, only in toy projects, so perhaps others will have more nuanced perspectives. Most of my resolvers take an ID as input and return a set of attributes for that entity, possibly including a join to another entity with that entity's ID. With that setup it's pretty clear where attributes are coming from. You can also use pathom trace to examine what pathom did to resolve your query if you're ever confused.

👍 4

wasn't aware of pathom trace, thanks for pointing that out

👍 4

@alidcastano hello, like @codonnell said, this is the killer feature for Pathom, I've been doing it for some time, and so far this hasn't been a problem, the biggest system using it that I worked on had close to 2000 different attributes, when you start to get to this size, what I see is that there are some "hub attributes" (usually ids, that correlate things) while most of attributes appears only once in the resolvers, since you don't actually get many options for the same thing (altough it is supported) it's usually easy to figure how something got there, and the tools are also there to help with it, makes sense?

👍 4

haven't played around with code yet, just reading docs, so only other question I have is - if you try to access a property that can't be resolved, what happens? would be nice to have a compiler similar to Relay that warns you so you don't encounter an error at run time


In practice you have tools like to visualize all the ways certain attributes are reachable. These indices are also used by tools like and to implement auto-complete for interactive query building (if it's not auto-completing, it means you're writing a query that won't resolve). I suppose you could use these same indices and tools to write similar kind of linters for compile/runtime.

👍 4