This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2022-06-09
Channels
- # announcements (12)
- # babashka (22)
- # beginners (17)
- # boot (6)
- # calva (45)
- # clj-kondo (17)
- # clojure (70)
- # clojure-australia (4)
- # clojure-europe (35)
- # clojure-finland (6)
- # clojure-losangeles (2)
- # clojure-nl (1)
- # clojure-uk (2)
- # clojured (26)
- # clojurescript (10)
- # conjure (1)
- # datahike (1)
- # events (1)
- # honeysql (14)
- # introduce-yourself (5)
- # jobs (5)
- # joyride (2)
- # minecraft (6)
- # off-topic (5)
- # pathom (14)
- # rewrite-clj (1)
- # shadow-cljs (13)
- # tools-build (6)
- # tools-deps (13)
- # vim (29)
- # xtdb (8)
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
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
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