Fork me on GitHub

A pc/defmutation takes two arguments: env and a second argument. Is it true that the second argument would be defined as 'query params' rather than 'input'? I'm thinking it would make sense to have 'input' as well (so a third argument). That way the caller could provide the mutation with different inputs to that which the mutation needs, much the same as can be done when calling resolvers.


@cjmurphy fun you mention it now, I've been recently playing with a similar idea, but instead of adding a new param, I made a transformer that automatically resolves the mutation params from the user given params, its like getting what the user sent, use as context to run what the query in ::pc/params, and them send that resolved result as the params


not finished, but the current code:


(defn resolve-mutation-params
  (update mutation ::pc/mutate
    (fn [mutate]
      (fn [{:keys [parser] :as env} params]
          (let [params-eql      (::pc/params mutation)
                resolved-params (->> (parser
                                       (-> env
                                           (assoc ::p/entity (atom params)))
                                       params-eql) <?
                                     (p/elide-items p/special-outputs))]
            (<?maybe (mutate env resolved-params))))))))

(pc/defmutation delete-todo [env doc]
  {::pc/sym       `todo/delete
   ::pc/params    [::pdb/id ::pdb/rev]
   ::pc/transform resolve-mutation-params}
  (pdb/remove-doc env doc))


I like the idea of the caller being explicit about the difference. Like you say in the docs a 'query param' (that's Tony's term from his plugin used in RAD, to give params to all resolvers) is not involved with dependencies, is used for sorting and things like that, whereas an input is about dependencies and is more commonly used. At the end of the day a mutation is not unlike a resolver, and a resolver has both ideas, so for consistency a mutation could also have both ideas?? I mentioned in the Fulcro channel that multiple resolver inputs did not seem to be formally supported by Fulcro. I would guess that people sometimes use params where they would be better off using inputs.


altough I agree they are similar, in pratice params are way more common in mutations than in resolvers, and that's I think its big enough to worth the difference in usage, so I think I'll stick to this idea for the library, but in the same way I'm creating that transform, you can create your own that behaves in the way you described, it can even add the third argument you mentioned


Cool thanks ­čÖé

╬╗ustin f(n)22:01:49

Hi, I am trying to use pathom on the server side. Is there a straightforward way to setup Pathom Viz tools in a way that it can work from a parser that hasn't been built with CLJS in mind?