Clojurians Log v2
pathom
Is there documentation on how to specify a mutation that requires particular input/s? My use case is a mutation that needs to know the current user (which is available via an output only current-user-resolver).
@cjmurphy I just do (let [user-data (parser env [...])]) inside mutation
But I think that you can do something with pc/transform too
Something like this? https://gist.github.com/souenzzo/362819e5088db5f4a089103602dc68f0
Currently every mutation has 2 args, first being env and second being params. If inputs were first class citizens then there would be 3 args, with the extra one being inputs. I guess it is some kind of a plugin that would provide that. Not sure your code is that generic. I know @wilkerlucio was experimenting with something that did that. Not sure if it was finished or documented.
@cjmurphy they are different concerns, params are for mutations what input is for resolvers, but they are different in the sense that params are sent as-is, you can make a plugin to auto-resolve the params on mutations, the arity 3 could be a thing, but not sure at this moment
Also I'm trying to develop a "style guide" to help us to know/remember/develop that kind of "pattern" in EQL ecosystem :) https://github.com/souenzzo/eql-style-guide#pathom
Re. your style guide there is a comment that doesn't seem to apply to the code below it.
I called the parser again, but from a function so can explicitly see all the cases. As it happens the current user is in the env so I could have just grabbed directly.
What would make sense to me would be if inputs were 'first class citizens' for mutations, which I think can be done with a plugin. And I was just wondering if it had been documented. Possibly that's the pc/transform you mentioned. For me is seems nice to only use standard plugins.
Something like this? https://gist.github.com/souenzzo/362819e5088db5f4a089103602dc68f0
I see this mutation in an example. Does pathom guarantee mutations are run in order? Does it depend on configuration (https://wilkerlucio.github.io/pathom/#_parallel_parser)?
[(log-in ~credentials) (finish-log-in {})])
@ericihli
[(op-1 {}) (op-2 {})] ~> both MAY be executed at same time (parallel parser will, serial parser don't
[{(op-1 {}) [(op-2 {})]}] -> op-2 will only start after op-1 finish.
But in general, isn't a good idea compose mutations in EQL
Prefer [(log-in+finish-log-in ~creds)]
Currently every mutation has 2 args, first being env and second being params. If inputs were first class citizens then there would be 3 args, with the extra one being inputs. I guess it is some kind of a plugin that would provide that. Not sure your code is that generic. I know @wilkerlucio was experimenting with something that did that. Not sure if it was finished or documented.
@cjmurphy they are different concerns, params are for mutations what input is for resolvers, but they are different in the sense that params are sent as-is, you can make a plugin to auto-resolve the params on mutations, the arity 3 could be a thing, but not sure at this moment