@wilkerlucio I essentially wanted to write ‘This mutation requires these parameters explicitly and these resolver’s outputs implicitly, Connect resolve the latter for me please’ your way is the manual version of that. I’m okay with that solution as well but I think somewhere read that in Connect there is only a fine line between resolvers with side-effects and explicit mutations, so I assumed ::pc/input would work (to fetch from env/call resolve automatically) the same.

@thenonameguy not really, but you can use mutation joins to request extra data, and you could write your own plugin that does that, I would suggest a different key (something like ::expose), if you add that key to your mutation it will stay there (the config is an open map, you can add anything you like)

so in the plugin code, extending with ::p/wrap-mutate you can pull that and execuse (using a parser call)

makes sense?

yup, thanks!

since you are already here

have you considered how Pathom could make use of the nav and datafy protocols? REBL seems like the same graphy-domain-exploration-thingy that Pathom could be if it had larger reach

@thenonameguy yes, it could use it to expand data, I didn't got the chance to play with that yet, but I imagine that you could the current auto-complete features to extract context, and probably suggest possible paths, so you could keep navigating

hey @wilkerlucio, I tried to use Pathom Connect’s Index Explorer with transit+json encoding, and since the returned ::pc/indexes contain functions the encoding fails as by default transit doesn’t have a handler for fns. Would it make sense to update the example resolver code in the docs to remove these fns via postwalk?

I assume they won’t be used

(pc/defresolver viz-index-resolver [env _]
  {::pc/input  #{:com.wsscode.pathom.viz.index-explorer/id}
   ::pc/output [:com.wsscode.pathom.viz.index-explorer/index]}
  {:com.wsscode.pathom.viz.index-explorer/index (walk/postwalk #(when-not (fn? %) %) (get env ::pc/indexes))})

this way the Index Explorer works (and is AWESOME! 🎉 )

@thenonameguy that's a concern outside pathom scope, for example, if you are using a local parser in CLJS, would be fine to send fns there (since there is no encoding needed), we may even inspect that fn, but I understand that its a common pitfall for users of the backend, a solution that I suggest is to setup transit default handlers, I think this is a good practice since after that nothing will break your encoding (and I believe that's what a lot of people would want)

sure, just a note would have been nice. As I think most people are going to use Fulcro with PC and I pulled some hairs out trying to figure out why it didn’t work. This is what I would need to patch: https://github.com/fulcrologic/fulcro/blob/develop/src/main/fulcro/websockets/transit_packer.cljc

and with the current setup I just got a network disconnect after 30 seconds, without any error response/logging server-side (which I know is a Fulcro WS wrapping issue but it was frustrating).

@thenonameguy agreed better docs are needed since its a common pitfal