Clojurians Log v2

I got it working! Thanks for the help y’all

hello, for your case @tekacs, you can go around this limitation by writing a mutation that sends multiple messages at once

or, some sort of mutation that composes other mutaitons

I ended up co-located the clj/cljs mutation files so they have the same namespace in the mean time

@wilkerlucio I merge queries into one until it can be sent, on retry it does one single query with all the pending ones

right, what yenda said @wilkerlucio

merging them into one doesn't really help, because it'd break ordering for one thing

[(mutation-1)
 (mutation-2)
 (mutation-1)]

the only real option as far as I can tell is to manually split the mutations externally to Pathom and then to send them into the engine one at a time 😞

I guess I could write a mutation that composes other mutations...

but would be wonderful if there were an ad-hoc way of simply giving each mutation its output name

which is why I was wondering if it could return a collection of results when the mutation was called more than once

if I'm not mistaken that would not even break existing queries, since for instance

(defn block-user
  [user-id blocked?]
  {(list 'block-user {:user/id user-id
                      :user/blocked? blocked?})
   [:user/id
    :user/blocked?]})

if we could rename outputs, then we could get the same effect as a collection by transforming queries to/from a form with renames

that's why that'd be my aim

I might see if I can do that in a plugin

If I'm not mistaken the overwrite occurs in mutate and mutate-async when the result is merged in the env

mhm actually looks like it's in the parser

(recur (assoc res (ast->out-key ast) value) tail)

would it be acceptable to do

(let [out-key (ast->out-key ast)
      previous-res? (get res out-key)]
  (recur (if previous-res?
           (update res out-key (fn [previous-res]
                                 (if (vector? previous-res)
                                   (conj previous-res res)
                                   [previous-res value])))
           (assoc res out-key value)) tail))

@yenda the vector thing is a problem, because it breaks the assumption that mutations always return a map, I think a behavior like that could be confusing. there is a plugin entry point that I've been considering for a while, and I think it could solve this problem, is a ::p/wrap-output, something to run exactly when pathom is building the output, with this hook you could either write a plugin to use some param and have some different output name (like alias works for reads today) or even make what you are suggesting. this was planned for Pathom 3, but I can make in Pathom 2, this can also give some room to experiment with this entry point

yeah the plugin way would be satisfying enough, I had the assumption mutations would return a vector when ran more than once like resolvers when they return more than one result 😄

I would curious to hear if there any plans to add Pathom 3 defresolver-style sugaring (inference of params, output, removing env/params) to the defmutation syntax, at all?

maybe, I didn't started mutations in Pathom 3 yet

but I think it should, just instead of inferring inputs, it will infer params