Fork me on GitHub

@wilkerlucio Would you mind elaborating on mutations? I’m struggling to see what value they offer when it takes a direct reference to the mutation var to initiate one. How is that any better, or worse, than invoking a function directly?


mutations are the "call side" of EQL, if you are not exposing the graph with some external EQL (meanding you are just using pathom internally), you could replace most of it with a regular fn call.


another difference is that mutation responses are also integrated with Pathom, so a mutation may respond with just :user/id, and the requester will call the mutation and ask for extra data, like: [{(create-user {...}) [:user/name :user/email]}]


in Pathom 3 there is another interesting thing for mutations, that is to auto-resolve the mutation params, in this case you can use Pathom engine to help materialize the params using the resolvers, for example, if a mutation requires :user/full-name, but the user invokes it with {:user/first-name "foo" :user/last-name "bar"}, Pathom can process the :user/full-name and send the params in this way

😄 1
💯 1

Yeah, yeah, that’s super helpful…


Although, I was under the impression that auto-resolving of params wasn’t handled automatically…


Ah, mutation-resolve-params


K, that’s really helpful, thank you.


happy to hear feedback on that, this feature didn't got so much usage yet, one of the things that's not clear is what should happen if the params can't be fulfilled, for now it will throw, but I'm willing to change depending on the discovery of new use cases


I don’t care for the syntax around invoking them, namely having to include the namespaces.


I wonder if the same goal could be achieved through a namespaced keyword.


Or dealing with quoted function names.


> it takes a direct reference to the mutation var to initiate one @U0HJA5ZQT if I understood you correctly it's not the case: mutations are referenced by (typically fully-qualified) symbols, calling of mutations defined by pco/defmutation is just a convenience, e.g. [( {:x 1})] is essentially the same as [( ~{:x 1})]`


@UDQ2UEPMY what you described is the Fulcro behavior around mutations, Pathom 3 is different in terms of calling it, in Fulcro, when you call a mutation, it returns a reference to the call (so you can kind transparently do it), in Pathom 3 this will actually invoke the mutation, so doing [( {})], is going to call the mutation and put a map on the query, which is usually not what you want


mutations need to be quoted because they are, in principle, a "call over the wire"


so its about sending a command to be executed by the processor


@U0HJA5ZQT mutations are symbols to separate their semantics from the semantics of attributes, mutations are commands, attributes are data points


@wilkerlucio: Yes, it’s just that with regular resolvers, the namespace in which you make a query is decoupled from the ultimate source of the data. You don’t have to know where the data is to get it. With mutations, there’s at least a sense of having to know “where” the mutation resides. Feels jarring in contrast, is my only point.


(And has one additional point of coupling—that of a namespace.)


are you meaning about the name of the mutation? you can override that, for example:

(pco/defmutation create-todo [...]
  {::pco/op-name 'acme.todos/create}


now, this mutation will be invoked by ['(acme.todos/create {...})]


Mmm, gotcha. Okay, thx.

👍 1

in Pathom 2 that's also available:

(pc/defmutation create-todo [...]
  {::pc/sym 'acme.todos/create}


@wilkerlucio: Coming back to mutations… You note in the documentation that resolving params in mutations has a performance hit (naturally). Is that hit large?


Also, is there a simple way to make that choice on a per-mutation basis?


its the same cost as if you ran the query by yourself inside of it, so it depends on how complex the resolution is


no way to set per mutation, but thats easy to make, a bit of change on the plugin code we can check for some flag in the mutation config


Okay, thx! I’ll see how it goes turning it on completely.


Sorry to bug you with this again, but is this expected behavior?


It appears that upon enabling the plugin only keys explicitly declared in params are available. That seems to prevent the possibility of using optional keys, unless added to a grab bag key.


yes, its expected, because it becomes a query like running from eql/process, but I see it might need better documentation


I encourage you to copy the code from the plugin and adjust for your needs in case you want a different behavior


and no worries about bringing those, love to get those feedbacks 🙏


Cool, it’s good for now… I’m just adding those keys one level deeper.