Fork me on GitHub
#pathom
<
2019-04-22
>
souenzzo03:04:24

How about that optional "syntax" to define mutations/resolvers https://gist.github.com/souenzzo/a0f9624e7dd20589ca9ad8905334b7cc PS: ::pc/kind isn't a good name

👍 4
wilkerlucio12:04:35

@souenzzo I'm not seeing much gain with this syntax, whats about the pc/defresolver or pc/resolver that doens't work for you? you can also use a plain map:

(def my-resolver
  {::pc/input #{...}
   ::pc/output [...]
   ::pc/resolve (fn [env input] ...)}

souenzzo17:04:14

@wilkerlucio it's "hard" do test At the end, it's just a function with some metadata Testing shoud be (my-resolver {:data 33} {:param 22}) => {:result 11}. ATM to test I always need to repeat (let [resolve-fn (::pc/resolve my-resolve)] ...) I'm already using that var-metadata version internally. Not sure if pathom should care about that. Maybe pathom should KISS and always expect maps..

wilkerlucio18:04:32

@souenzzo if calling is the problem, you can make a helper for that: (defn call-resolver [resolver] ...), that seems the easiest path me, what you think?

👍 4
souenzzo19:04:08

I'm using var metadata and I'm very happy with it. I will see if it scale or not, then I feedback I think that many libs like #clara can also use var metadata too.

wilkerlucio19:04:05

@souenzzo pathom used to suggest multimethods, the problem is when you want to break things apart, in many cases I found myself wanting to break down indexes (use just parts of it), specially for testing, and multimethods make close to impossible to separate once they are glued, that's the main motivation for the new design, keep things separated and make it easy to join

wilkerlucio19:04:21

you can just def vector with all the resolvers and that's composition for pathom