Fork me on GitHub
#pathom
<
2021-02-19
>
wilkerlucio12:02:32

๐ŸŽ‰ New docs for how nested input filtering behaves: https://pathom3.wsscode.com/docs/resolvers#nested-inputs-filtering

๐Ÿ‘ 7
wilkerlucio13:02:29

๐ŸŽ‰ 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

8
๐ŸŽ‰ 1
wilkerlucio13:02:50

@U0D5RN0S1 if I remember right you were looking for this one a long time ago

bananadance 1
fjolne16:02:34

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

wilkerlucio16:02:26

not this plugin directly, but you can make a transform for that

๐Ÿ‘ 1
royalaid16:02:59

@wilkerlucio Looks like submitting invalid queries can cause the UI to lock up on Pathom Viz

royalaid16:02:24

i.e. [{[:curriculum/uuid <snip>]}]

royalaid16:02:50

Which is missing the value to the map which should def. error

royalaid16:02:58

but the UI shouldnโ€™t require a hard reload IMO

wilkerlucio17:02:14

agreed, can you please open an issue at the pathom viz repo?

royalaid17:02:09

Side note, thanks for the amazing tool!

๐Ÿ™ 1
dehli19:02:52

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.

wilkerlucio19:02:42

no support for that

dehli19:02:18

๐Ÿ‘ 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

markaddleman20:02:13

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.

dehli21:02:44

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

dehli21:02:00

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 .

dehli21:02:59

I bet if you updated the field-list input to be this it would work: (pco/? {:attributes/profiles [(pco/? :attribute/id)]})

dehli21:02:35

or another option would be to mark :k2 as optional in your profile-attributes resolver

wilkerlucio21:02:31

@U2845S9KL before I check it closer, did you upgraded Pathom today? because today I made a fix related to nested optional inputs

wilkerlucio21:02:43

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

markaddleman21:02:15

Yes, I'm using head

markaddleman21:02:19

doh - Thanks for the arity 3 pointer. That simplifies things.

markaddleman21:02:49

@U2U78HT5G

(pco/? {:attributes/profiles [:attribute/id]})
does not pass a guardrails check. I've been meaning to ask if it should

wilkerlucio21:02:47

@U2845S9KL wrong place, this is how you do it:

{(pco/? :attributes/profiles) [:attribute/id]}

๐Ÿ‘ 2
wilkerlucio21:02:58

I just tested, that got some results with your code

wilkerlucio21:02:05

and the things that @U2U78HT5G said were accurate

wilkerlucio21:02:14

its the k2 missing dep that's making pathom give up on that

wilkerlucio21:02:02

Im quite happy how you are pushing the boundaries, will be even happier if all works as expected XD

1
markaddleman21:02:32

No worries. I sort of expected this when I decided to go P3.

markaddleman21:02:56

And, to be sure, P3 is proving to be a win for me overall

markaddleman21:02:48

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

wilkerlucio21:02:29

I'm gonna check that, in the meantime, what about optional on :attribute/profiles?

markaddleman21:02:39

That works but... (i think I tried earlier and had a problem)

wilkerlucio21:02:06

about the optional :k2, I believe its behaving correctly, you made that optional, so it runs the resolver and retuns the list

๐Ÿ‘ 1
markaddleman21:02:24

This yields the correct result:

::pco/input  [{:attributes/dimensions [:attribute/id]}
               {(pco/? :attributes/profiles) [:attribute/id]}]

markaddleman21:02:56

However, this

::pco/input  [{(pco/? :attributes/dimensions) [:attribute/id]}
               {(pco/? :attributes/profiles) [:attribute/id]}]
produces a guardrails exception

markaddleman21:02:10

And this ^^ is closer to my real use case

wilkerlucio21:02:21

interesting, I have a guess on why ๐Ÿ‘€

wilkerlucio21:02:41

ok, that seems a simple spec oversight, the result is correct?

wilkerlucio22:02:20

spec fixed on master

๐ŸŽ‰ 1
markaddleman22:02:15

I haven't tried turning off guardrails. I'll update to newest master and retest in a few minutes

markaddleman22:02:49

Under latest master,

::pco/input  [{(pco/? :attributes/dimensions) [:attribute/id]}
               {(pco/? :attributes/profiles) [:attribute/id]}]
produces correct results

wilkerlucio22:02:47

I usually use guardrails with throw false

wilkerlucio22:02:53

so even when it complains, things still go on

๐Ÿ‘ 1