Fork me on GitHub
#pathom
<
2022-06-09
>
JAtkins03:06:00

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?

roklenarcic08:06:13

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

nivekuil09:06:59

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

JAtkins09:06:42

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

JAtkins17:06:12

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

wilkerlucio22:06:19

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

👍 1
wilkerlucio22:06:38

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

JAtkins08:06:00

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
roklenarcic15:06:56

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

wilkerlucio15:06:43

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

wilkerlucio15:06:04

for now the solution is to break those in separate resolvers

roklenarcic15:06:00

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

roklenarcic15:06:10

but thanks for clarifying

wilkerlucio17:06:33

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