Clojurians Log v2
pathom
nice! thanks for the example, didn't know about p/do
glad to help, also check p/let, I find that super useful
I think the last commit has a regression: ast only has the value map of`:params` in it. maybe this should be ast on this line? https://github.com/wilkerlucio/pathom3/blob/1da7457bf65dbcd57cc9a7e98bc7eeee7bf6705b/src/main/com/wsscode/pathom3/connect/runner/async.cljc#L348
e.g.
::pcr/wrap-mutate (fn [mutation] (fn [env {:keys [key] :as ast}] (log/info ast) ...))(get ast :params), so key is niloh, sorry, you are right, this was because I also wanted to enable the user to override the output, and for that I changed the place of invocation of it, fixing it now
fixed on master https://github.com/wilkerlucio/pathom3/commit/523dab6c4d9c9c9bc2df323a86b4f4e9833f66bb
I'd like to ensure that all all resolver inputs are smart-maps. I have written this plugin:
(p.plugin/defplugin as-smart-map {::pcr/wrap-resolve (fn [resolve]
(fn [env node]
(p.ent-tree/swap-entity! env (fn [m] (if (psm/smart-map? m)
m
(psm/smart-map env m))))
(resolve env node)))})Thanks for the feedback. I ended up adding the required parameters to the resolver's input. At first, it seemed a little weird because it wasn't the resolver directly that required the parameter but a downstream function which, in another context, was obtaining its parameters from a smart-map.
Right now, I'm leaning towards your opinion: Wrapping a resolver's input as a smart-map is a bad idea.
in case the distance between input and the calling part starts get apart, one thing to consider is if there aren't more resolvers in between that could add clarity to the process
I don't understand this. How would I place a resolver between a resolver implementation and a downstream function?
this is hard to explain without a concrete example, can you give a quick version of how you doing this, where the input is farther from the resolver call?