pathom 2021-08-16 | Slack Archive

Is P3 able to distinguish based on nested outputs? Say I have the following two resolvers:

(pco/defresolver something-else
  [_ _]
  {::pco/output [{:container [:something-else/id]}]}
  {:container [{:something-else/id :bar}]})

(pco/defresolver something
  [_ _]
  {::pco/output [{:container [:something/id]}]}
  {:container [{:something/id :foo}]})

can I then disambiguate with a nested query like:

(p.eql/process  
 env2
 {}
 [{:container [:something/id]}])

From basic testing in the repl it doesn’t seem so… the resolver last in the pci/register call wins, so is this something P3 cannot do?

wilkerlucio19:08:53

hello Donavan, I have plans to support it, good to know about someone trying to use it, I kinda started but didn't finished that part yet: https://github.com/wilkerlucio/pathom3/blob/master/src/main/com/wsscode/pathom3/connect/planner.cljc#L926-L928

donavan19:08:49

Awesome 😄

kendall.buchanan20:08:39

donavan14:08:05

@wilkerlucio I took a stab at implementing this… would it best be done in the initial planning phase or as in the optimisation phase?

wilkerlucio15:08:43

I add the comment in the part of code that needs to change, thats inside that function

donavan15:08:25

mmmm, that function is never called when I try run the example above

donavan15:08:05

…but that answers the question, it’s during initial planning not optimisation which is what I would expect

wilkerlucio15:08:44

mmm, there is another problem to this situation that occurred to me

wilkerlucio15:08:03

the nested checks are only done for dynamic resolvers, not for static ones

wilkerlucio15:08:56

that's something to consider, if the planner should try going on nested things always, have to think about how that could impact performance

royalaid19:08:38

@wilkerlucio I am working through integrating guardrails into our in-house pathom2 macros. What would be the best way to go about supporting it? My current through it pull out the gspec parsing and run-check functions in guardrails and use those in the forms emitted by the macros

royalaid19:08:01

Ideally this will look like an addition gspec line in the pathom mutations/resolvers

wilkerlucio19:08:47

@royalaid if you add specs to a macro, they will always run automatically by Clojure

royalaid19:08:16

Right but I want to add gspec style arg checking

royalaid19:08:43

I am afk atm but will sketch out an example once I am back at my keyboard

royalaid21:08:50

(pc/defresolver ex-one
  "Example Resolver"
  [{:keys [foo}]
  {:stack/code-url (when foo
                     (str "" foo))})

royalaid21:08:36

So for the above I imagine something like

royalaid21:08:53

(pc/defresolver ex-one
  "Example Resolver"
  [{:keys [foo}]
  [map? => map?]
  {:stack/code-url (when foo
                     (str "" foo))})

royalaid21:08:18

For the sake of example, this is a terrible spec but it illustrates what I am trying for

wilkerlucio21:08:26

you should consider if its worth to do it, resolvers will always be [map, map] => map (exception on batch, which is [map (coll map)] => (coll map), so what is the gain to add it? another idea is to instead use a plugin, with a plugin you can read input/output descriptions strait from the resolver, and than you can run spec checks on top of that

2021-08-16

Channels