I’m having trouble finding pf.eql/data->shape , it doesn’t seem to be in com.wsscode.pathom3.format.eql, all I can find is data->shape-descriptor in com.wsscode.pathom3.format.shape-descriptor nvm, I was looking at main :D

not even performance really, this one improves the Index Explorer, now attributes that are only nested will also be listed there (they were missing before this issue is fixed)

I’m a little confused what the index-explorer is. Is it related to debugging?

its a tool in Pathom Viz, to explore the available attributes, resolvers and mutations

;

Ok so it wouldn’t really change how querying works. Just indexing for debugging?

yup

also for anyone writing tooling based on the attributes index, now there is more info there

Ah ok interesting. I was playing around with PathomVis yesterday and discoverability wasn’t working as intuitively as I would’ve thought. I figured perhaps this might’ve fix that. It hasn’t though. I show you an example of what I mean

I just DM’d you a screen recording.

Also I just realised it’s not even a nested attribute.

Anyway thanks for clarifying about that issue

I think this feature could simply output map that follows the same structure as the query result where the leaf values are replaced with the name of the resolver.

On second thought, it might be more complicated than that for collections

sounds like a job for a plugin that adds some metadata to the response?

Yeah, I’ve been thinking about writing a plugin to handle this

In every case where I’ve needed it, I’ve just resorted to sticking println statements into the relevant resolvers because it’s easier at the time 😕

hello Mark!

there is already something like that, when using the trace tool you should be able to see the execution graph, which will tell you what resolver got called

this data is also available in the entity itself, if you check the meta on the entity, it includes the whole execution graph

with a bit of fiddling you can write some helper that given an entity and an attribute, it tells you what resolver (or resolvers, it might have attempted more than one) computed that property

I think I’ve tried the trace tool (it’s been a while since I had this problem). I think it was cumbersome for large plans or output.

I’m sorry I can’t be more specific. Next time I run into this problem, I’ll be sure to report more details

Your suggestion about using metadata and a helper tool is a good idea

I’m glad the data is already there 🙂

Thanks!

Yeah, it's so awesome that Wilker exposes all of this information! I am working on a Clerk viewer for the Pathom resolver dependencies where I leverage this. Check https://gist.github.com/pfeodrippe/e61eaaed6adcd87977fe2bb8d435e129, the code is based on one of https://pathom3.wsscode.com/docs/tutorials/babashka (just modified to introduce clerk). The dependency dev-tooling is just a big bag of code where I experiment with lots of stuff, feel free to use anything from there if you want. tool.pathom/process-query should be a drop-in for p/process (arity 3), so you can visualize and inspect any query you already have available on your own code. It's still an experiment, so use it with a grain of salt. I've made a small video (no audio) so you can check this out without having to run it on your own, see the usages in the REPL and later with Clerk.

I think Clerk is a nice way to play around with Pathom and to demonstrate it’s usefulness. I was also playing around with it to explore a SQL db (still WIP)

@U5R6XUARE Did you consider pushing your work to Clerk garden? I just pushed a https://github.clerk.garden/jeroenvandijk/hello-garden, I hope to extend it with more Pathom later. It is easy to setup and I believe it is doesn’t have many restrictions in what you can run in it

@U5R6XUARE Very cool, thank you. I wonder how hard it would be to include a Clerk viewer for graph visualizations like in the Pathom docs. Clerk could be a nice way for sharing repros for troubleshooting and documenting Pathom stuff.

@UPWHQK562 I think this discussion is related https://clojurians.slack.com/archives/C035GRLJEP8/p1675146154406729 I’m guessing this will be feasible at some point

Although this was about README’s for normal html documentation it would already be possible I guess

@U0FT7SRLP @UPWHQK562 Yeah, we can try doing something, Pathom Viz should already have all of the introspection we need, it’s just a matter of creating a more focused view for any specific needs we have. We can continue the convo in another thread if you want so we don’t add more pings to Wilker’s notification ahahahah

also, for some basic stuff, you can use the pathom viz embed, its super easy to setup, a simple iframe does the job

but, there is a caveat, the simpler usage involves sending data via query params, which has a limit on the payload size, that can overflow with ease by pathom

so a proper setup involves loading the iframe, and communicating with it via postMessage, that gets rid of the payload size limit, but its not as easy to setup