Fork me on GitHub

@yenda they are different, mutations return errors in place (as they are always flat and at the root) while the other errors are separated, if you want to change you can write a plugin with a {::p/wrap-parser ...} so you read the mutations (easy to detect: symbols at the response root) and more then to the errors map, makes sense?


If a mutation depends on inputs, that in turn depends on inputs etc, then the mutation is no longer at the root. Inputs to mutations are considered rare, and doubtless would not go very deep, but I seem to want to use them all the time.


you can do that without changing the structure, something that I find interesting is to use mutation params as a base and then resolve to the required params, for example, lets say your mutation requires some :user/name, but the user calls the mutation with (do-something {:user/id}), pathom can figure the name from that


doing it this way it keeps it flat and on the root, and at the same time gives more freedom to the caller (doesn't have to send the exact mutation requirements, as long as there are resolvers available to get there)


So inputs you send to mutations go through resolvers. Or looked at the other way params to mutations have been through resolvers already, so if there's a way (using Pathom indexes) to go from :user/name to :user/id and you send a :user/name to a mutation that requires a :user/id as param then all will be fine. (I reversed your example as I would tend to have a name in the UI during development).