the entity input doesn't flow to the mutation params, they are their own world, so this is the expected behavior

Oh. I thought that in Pathom3 inputs were going to be 'first class citizens' for mutations. The model I seem to want to understand, and others too, has params and inputs as separate things. And both mutations and resolvers have them in the same way.

mutations are a different dimension and their params don't mix with inputs, it was never the plan to mix them, that said, you can make plugins to mix them if you want, but in Pathom mutations are design to be very self contained (@U067NFWUR made it here: https://gist.github.com/loliveira/5c907135b5a40be747aeb527666b7b7c)

the mixing of inputs and params, IMO that can lead to confusing situations where a mutation operation would vary based on things not other than the mutation call itself, in Pathom the mutations are made to favor predictability (making sure your mutation call is consistent with just the params you send, a single point to check whats coming in)

Yeah I never want to mix params and inputs either. They are separate things. Mutations have params only. But it would be good if they can have inputs as well, the way resolvers have params and inputs. That way mutations can for instance pick up global inputs.

If Pathom users want their mutations to be predictable then they don't need to specify them to take inputs (just params - the usual case). Sometimes you just want your mutation to see something that you know can be resolved.

@U0D5RN0S1 that's covered with the pbip/mutation-resolve-params, in that way the ::pco/params will use Pathom to fulfill it, is just the part of bringing the current entity (which is the input) mixed in the game that I dont think is a good idea to mix in

I was just thinking of the defresolver macro having the args [env inputs params] and the defmutation macro having the args [env params inputs]. So keeping params and inputs completely separate. The last arg in both of them being optional. So nothing special.

I'd like to be able to understand why this isn't a good idea.

hello @U0D5RN0S1, I'm really not looking forward to change arities on resolvers and mutations (a lot of things depend on this arity, making more would complicate everything), you can make your own macro to support those if you want, I already mention the reasons why I don't think using inputs in mutations is a good idea, to be honest I had some thoughs about this in the past, but never had the time to explore, so I wont put something at library level that I'm not comfortable with. also, remember you can explore and play with this idea yourself by creating some plugins and/or custom macros (to support he arities you are looking for). I'll be happy to learn more about how it goes in your experience, but not looking for this changes ta the library at this point

Okay thanks. I guess I never really understood those reasons. A little bit of documentation might really help the confusion that I think exists out there, although hopefully Pathom 3 makes it all a bit more obvious. For example in the code I'm maintaining at the moment the mutations have inputs declared!! From Fulcro you can often just have what might be inputs in app state, and deliver them as mutation params. The problem comes more with session attributes that feed easily into resolvers, and then why not mutations as well?? Back to the documentation plea - if your audience know why inputs are not supported for mutations, then they won't have any trouble remembering that they're not supported! Thanks for all your great work by the way 😄

and I like to say I really appreciate you being around for so long, I still remember when we had a chat during a Clojure conference at lunch time around those, very early days 🙂

I'm all in for improved docs to make these things more clear, do you have a suggestion on that?

I've never been to a Clojure conference, but I've certainly been around Fulcro for a long time. Docs are hard and what's worse is lots of people don't read them. I've recently read the XTDB docs - they were good b/c they told a story - so much better than the Datomic docs! Your SpaceX talk was great from that point of view (there's another talk out there where s/one actually copies your talk ha!). That's why the Brave Clojure book does so well. Say telling a story setting up a logistics application, repairing Pathom code badly done that has bugs that need to be solved along the way, that shows how much can be done w/out plugins and macros. You did ask!

Interesting discussion… Just my 2 cents, but I was surprised that mutation-resolve-params is for all mutations? I can’t just apply it to certain ones? Or, can I achieve that by using the mutation helper and just define pco/inputvs. pco/params as I like?

@UH13Y2FSA with a few adjusts its possible to make a version of mutation-resolve-params that applies to only specific mutations, a good way to determine if it should be used or not could be via some config in the mutation

Thanks, I suspect what I’ll end up needing is a way to resolve some, but not all the params, so I’ll look into what the mutation-resolve currently does.