This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2021-02-19
Channels
- # announcements (13)
- # asami (43)
- # babashka (35)
- # beginners (175)
- # calva (23)
- # cider (5)
- # clj-kondo (68)
- # cljsrn (4)
- # clojure (61)
- # clojure-australia (7)
- # clojure-europe (20)
- # clojure-gamedev (59)
- # clojure-israel (11)
- # clojure-italy (4)
- # clojure-nl (2)
- # clojure-norway (21)
- # clojure-spec (12)
- # clojure-uk (43)
- # clojurescript (9)
- # cursive (56)
- # data-oriented-programming (5)
- # datascript (1)
- # events (1)
- # fulcro (16)
- # honeysql (46)
- # leiningen (1)
- # malli (4)
- # off-topic (12)
- # pathom (46)
- # re-frame (24)
- # reagent (14)
- # reitit (1)
- # reveal (8)
- # rewrite-clj (16)
- # ring (13)
- # sci (9)
- # spacemacs (14)
- # specter (2)
- # sql (2)
- # tools-deps (1)
- # vim (2)
๐ New docs for how nested input filtering behaves: https://pathom3.wsscode.com/docs/resolvers#nested-inputs-filtering
๐ New built-in plugin, now you can easely make mutation params resolve like resolver inputs! https://pathom3.wsscode.com/docs/built-in-plugins/#resolve-mutations-params
nice! would be great to be able to apply this plugin non-globally to a single mutation in opts map, kinda like augmentation via pco/transform
@wilkerlucio Looks like submitting invalid queries can cause the UI to lock up on Pathom Viz
agreed, can you please open an issue at the pathom viz repo?
Can you specify params for specific inputs in your resolver? Iโd like to have a resolver depend on an input with a specific parameter always applied. My current workaround is to create another resolver that always applies the param but was curious if I could do it along with the input.
no support for that
๐ thanks! i think i can accomplish what iโm trying to do when i switch to pathom3 by using nested inputs along with the filtering of missing keys
Related to yesterday's discussion - Now my field-list resolver takes two separate inputs. Both of which can be optional. The first query returns the result I expect. The second query should only invoke the dimension-attributes, dimension->attr-id resolvers and field-list resolvers but returns an empty result instead.
I think this is b/c with your second option you only provide :k1
so it seems like itโs impossible to get to :attributes/profiles
which is not marked as optional in your field-list
resolver
The sub-key is optional but it still needs a key of :attributes/profiles
which pathom cannot get to with your second query since the only resolver that provides :attributes/profiles
requires both :k1
and :k2
.
I bet if you updated the field-list
input to be this it would work: (pco/? {:attributes/profiles [(pco/? :attribute/id)]})
@U2845S9KL before I check it closer, did you upgraded Pathom today? because today I made a fix related to nested optional inputs
one other tip, you can use the arity 3 on process
to make your execution result simpler (by removing the nesting under the placeholder):
(p.eql/process env
{:k1 "not empty"}
[{:pivot-table/fields
[:pivot-table.fields/count
:pivot-table.fields/list]}])
Yes, I'm using head
doh - Thanks for the arity 3 pointer. That simplifies things.
(pco/? {:attributes/profiles [:attribute/id]})
does not pass a guardrails check. I've been meaning to ask if it should@U2845S9KL wrong place, this is how you do it:
{(pco/? :attributes/profiles) [:attribute/id]}
I just tested, that got some results with your code
and the things that @U2U78HT5G said were accurate
its the k2 missing dep that's making pathom give up on that
Im quite happy how you are pushing the boundaries, will be even happier if all works as expected XD
No worries. I sort of expected this when I decided to go P3.
And, to be sure, P3 is proving to be a win for me overall
Yeah, if I mark :k2
as optional in the profile->attri-id resolver, field-list produces results but it's the wrong results. There should not be profile in the result from field-list because :k2
isn't in the input
I'm gonna check that, in the meantime, what about optional on :attribute/profiles
?
That works but... (i think I tried earlier and had a problem)
about the optional :k2
, I believe its behaving correctly, you made that optional, so it runs the resolver and retuns the list
This yields the correct result:
::pco/input [{:attributes/dimensions [:attribute/id]}
{(pco/? :attributes/profiles) [:attribute/id]}]
However, this
::pco/input [{(pco/? :attributes/dimensions) [:attribute/id]}
{(pco/? :attributes/profiles) [:attribute/id]}]
produces a guardrails exceptionAnd this ^^ is closer to my real use case
interesting, I have a guess on why ๐
ok, that seems a simple spec oversight, the result is correct?
I haven't tried turning off guardrails. I'll update to newest master and retest in a few minutes
Under latest master,
::pco/input [{(pco/? :attributes/dimensions) [:attribute/id]}
{(pco/? :attributes/profiles) [:attribute/id]}]
produces correct resultsI usually use guardrails with throw false