Fork me on GitHub

is there a way to tell pathom to pull all computable options for a key? e.g.

(defresolver spelling-error
  [{:keys [:text]}]
  {:errors [...]})

(defresolver not-actually-a-string-error
  [{:keys [:text]}]
  {:errors [...]})
I'd like pathom to compute both and concat the results. Clearly, this doesn't work, but is there a way to get this capability?


Why are they a separate resolver? I don;t think you can do that and I don’t think it will work like that in the future


you could make a super-resolver that directly calls those resolvers and concats them


@U66G3SGP5 Yeah, doesn't work like that now either 😛. Different resolvers because this is part of a plugin concept - allowing more outputs with no prior knowledge from the owner or the query-er. I could implement it with a super-resolver that has a registration mechanism for all providers, but that requires knowledge that a key might have many providers... Not terrible but still requires work. on the query-er side I don't want to know before hand that I'm looking for :spelling-errors and :wrong-type-errors .


The solution might be to write a custom pco/env or whatever it's called that takes resolvers and makes a mutation. If it sees many impls of the same key, it could write the super resolver into the env


this goes against a core premise of pathom that is: each attribute only gets resolved once

👍 1

could be possible, but I'm afraid it would add a lot of extra complexity to the internals


Yeah, I’ve just written a custom layer on pathom-indexes/register to find duplicates, prune them, and make a master resolver out of it

👍 1

If I’ve got more than one parameter set in the query, how do I get the other one? e.g.:

(pco/defresolver res1 [env _]
  {::pco/output [:user/first-name :user/last-name]}
  (println (pco/params env))
  {:user/first-name "Me" :user/last-name "OK"})

(query ['(:user/first-name {:x 1}) :user/last-name])
will print {:x 1} as expected but this will print the same:
(query ['(:user/first-name {:x 1}) '(:user/last-name {:y 2})])


parameters are per resolver call, most of the time they are used to filter a collection so there is only one attr there


for now the solution is to break those in separate resolvers


parameter could be something trivial like :uppercase? and that could go onto multiple attributes


but thanks for clarifying


I would not recommend, feels like pushing some aesthetic things to the data process, that to me sounds something you wanna do after the fact, but if its a business thing, I think would be better to have a derived attribute instead of making it a param