Clojurians Log v2
pathom
With pathom3, is there a way to access the options map that I pass into an operation inside of a plugin? I’d like to write a plugin that detects if a spec is passed in the options map and if so, validate the params before invoking the mutate. My thoughts are it could be used like below, and then the plugin would be responsible for validating the spec. If this isn’t possible, I could always wrap the defmutation with my own custom macro to accomplish this. Thanks!
(pco/defmutation my-mutation
[params]
{::pco/spec ::my-mutation-spec}
;; If this is executed, I know that params fulfills the ::my-mutation-spec
{::success true})
yes you can, its a bit different for mutations and resolvers, but both are accessible
in the wrap-mutate you get the AST, you can use the :key there to know the mutation name, use that to lookup into ::pci/index-mutations
a mutations is a record, you can get the options map with pco/operation-config
in the case of a resolver what you get is the node, the node has an ::pco/op-name, you can use that to find the resolver in the ::pci/index-resolvers
for convenience, use the helpers pci/mutation-config and pci/resolver-config
awesome, that helps a lot (and is awesome)! thanks for your guidance!
I would suggest name that something like param-spec to make it cleaner, and better to use your own namespace for it (to make the inference of ownership easier)
good call! i agree that name is cleaner. got it working as well! thanks again!
(p.plugin/defplugin params-spec
{::p.plugin/id `params-spec
:com.wsscode.pathom3.connect.runner/wrap-mutate
(fn [mutate]
(fn [env {:keys [key params] :as ast}]
(let [{:keys [params-spec]} (pci/mutation-config env key)]
(when (and (some? params-spec) (not (s/valid? params-spec params)))
(throw (ex-info "Invalid params" params
{:message (s/explain-str params-spec params)})))
(mutate env (cond-> ast
(some? params-spec)
(update :params #(st/select-spec params-spec %)))))))})
In Pathom (2), is there anyway to reconstruct env after (or during) a mutation? This is primarily because we need to use a new Datomic DB value after the mutation has run. The pathom-datomic plugin also seems to use an old DB value after mutation is run.
> works on reads Whether intentionally or not, it works on mutations too!
We're currently doing this after a TX to Datomic,
{…
::p/env (refresh-env! env db-after)
:tempids tempids}Inserting the updated DB, extracted from the response from Datomic (both for pathom-datomic and our on part of env). It works well.
> you could also keep db as something mutable in env (as an atom) and update it anytime you see fit (for sync process this should be fine, for parallel not so much)
We did this at first, and it was not great. Particularly, pathom-datomic didn't follow suit, but also it's fairly unergonomic. It's easy to get wrong.
with some cache issues, but it really work
(let [register [(pc/resolver `b {::pc/output [:b]}
(fn [{:keys [b]} _]
{:b b}))
(pc/mutation `a {}
(fn [env _]
{::p/env (update env :b inc)}))]
parser (p/parser {::p/plugins [(pc/connect-plugin {::pc/register register})]
::p/mutate pc/mutate})
env {:b 0
::p/reader [p/map-reader
pc/reader2
pc/open-ident-reader
p/env-placeholder-reader]}]
(parser env `[{(a {}) [:b]}]))In our case, we only needed it on mutations, as queries are the opposite: we absolutely don't want different parts of the query to use different DBs (or, the DB at different times). That can return some real frankensteinish results.
And for pagination, we want to be able to keep the DB timestamp stable until the user decides to refresh the query.
did something similar for one of my first plugin attempts, went the atom route
trying to remember if that works, but try returning a modified env in the key ::p/env in the return of the mutation data
Just saw that here: https://blog.wsscode.com/pathom/#updating-env Thanks! Going to check if this also works for mutations.
Thanks @wilkerlucio that worked :i_love_you_hand_sign::skin-tone-2:
Yep, that worked!
Hello everyone! I am trying to setup Pathom3 with Pathom Viz. I started here: https://pathom3.wsscode.com/docs/debugging#connect-the-app but I ran in the stacktrace: (short version)
Caused by: java.io.FileNotFoundException: Could not locate com/wsscode/promesa/macros__init.class, com/wsscode/promesa/macros.clj or com/wsscode/promesa/macros.cljc on classpath.@paul931224 seems like you are in an outdated version of pathom3, can you try the latest commit? (currently: d9a950c96f3fe3115a54679228dbf92c2ca06c9b)
My mistake, I had the good version a while ago, but somewhere in the process I must have overwritten it. Thank you very much! 🙂
::p/env only work on reads or in mutations too?
works on reads
no feature for that in pathom 3, maybe that will get add, but I remember having problems of reliability with it, gotta put some hammock time on it
like in some situations the env could leak out, I wanna Pathom 3 to be safer on that